Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SCJD - DuplicateKey Requirement

 
Paul Truckle
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My specification for the above states the the Create routine should check for a DuplicateKey scenario. However the spec does NOT state what the primary key requirement is ? Is this left down to us ? Shouldn't the update method also check for this....it could be possible to update a record with the same field values as another....hence duplicate key.

Can anyone throw any light on what Sun's interpretation of this is supposed to be ?

Many thanks.

 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul,

I choose not to throw the DuplicateKeyException, for the reason that there is indeed no spec (or not even a hint) of what the key would be. I think I got away with it without any penalty.

Frans.
 
Frank Verbruggen
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul,

I chose the same solution as Frans did.
Not to throw the DuplicateKeyException at all.
But, there is another possibility,
and that is to define what u think is a key, note it in choices and
make it a RuntimeException (that way, update can also throw it, because it needn't be declared), and throw it when necessary.
Good luck
 
Paul Truckle
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks very much for your help on this matter.

Cheers,


Paul.
 
Paul Bourdeaux
Ranch Hand
Posts: 783
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Paul,

This another one of those topics that has been debated many times on this forum, and I just wanted to give you another view other than that presented.

Some people have decided to implement a primary key, and document what it is and why it was selected in their choices.txt. Personally I feel that keys should be used.

I have the B&S assignment, and I elected to make the name and location fields my primary key. Some people have made the entire record a primary key. Others have chosen not to implement it at all, and all appear to have passed. Whatever your decision, make sure you document it and you should be fine.
 
Paul Truckle
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Paul.

I actually consulted Sun on this one.... and made a suggestion of name and location (which is what you chose). They said name + location is unique and would therefore be suitable.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic