This week's book giveaway is in the Design forum.
We're giving away four copies of Design for the Mind and have Victor S. Yocco on-line!
See this thread for details.
Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

B&S: Primary Key

 
Bhavik Patel
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ...

Thanks.
 
Jeremy Botha
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for the information .. I will document my decisions about it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic