• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S: Primary Key

 
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thanks for the information .. I will document my decisions about it.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic