In my assignment , the spec says clearly that if the method declares DuplicateKeyException to be thrown then it should do so if DuplicateKey found.
so i can not avoid this requirement and not throw DuplicateKeyException as i saw some people have just ignored this requirement in the past.
Now the question is what should be the primary key ..
recNo as primary key may create problem in case of create-delete sequence but locking should avoid this..
I have implemented name & location combination as composite key. I am setting the primary key object with keys(int keys) as member variable which sets the index of array fields which are primary key elements .. so in my case
In create method i check for duplicateEntry by comparing the name & location.and if its valid then just create new record,
in the update i am trying to check the new values will not violate the name& location(composite key) and if its all valid then & then update.
My concern is that if in any case primary key constraint is violated then the operationis failed throwing the DKE and message is logged .Does it fullfill the requirement ??any drawbacks of this decision ?? just wanted some views on this design ...
SCJP 1.4<br />SCWCD 1.4(91%)<br />Working on SCJD -Bodgitt & Scrapper Constructions...<br /> <br />"It takes 43 muscles to frown & 17 to smile but it doen't take any to just sit there with a dumb look on your face .. Keep Smiling "
Yes, the requirements say to throw a duplicatekeyexception if there's an attempt to generate a duplicate key. But as the requirements don't specify a key, there's no way (unless you, like you did, specify your own) to ever generate a duplicate key as there's no key at all
All depends on how you explain the requirements I guess, just make sure you (as always) document your decisions.
Joined: Jul 12, 2004
thanks for the information .. I will document my decisions about it.