SCJD - DuplicateKey Requirement

[Paul Truckle]

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]

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]

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]

Thanks very much for your help on this matter.

Cheers,


Paul.

[Paul Bourdeaux]

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]

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.