B&S: Primary Key

[Bhavik Patel]

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

keys = new int[]{0,1};//name,location

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 ...

Thanks.

[Jeremy Botha]

Pretty much what I did.

I've also documented around referential integrity in the user documentation, explaining what conditions will cause the exception to occur.

Jeremy

[Jeroen T Wenting]

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.

[Bhavik Patel]

thanks for the information .. I will document my decisions about it.