When to throw a DuplicateKeyException

[Frank Verbruggen]

When name/location pair is already known in the database,
of when all fields (except the "booked" field) match the input.

This is very unclear to me since NOTHING in the DB file specifies name/location as the key for a record !

[Ryan Tang]

Originally posted by Frank Verbruggen:
When name/location pair is already known in the database,
of when all fields (except the "booked" field) match the input.

This is very unclear to me since NOTHING in the DB file specifies name/location as the key for a record !

Yes, and I chose NOT to throw DuplicateKeyException in my data access class implementation.
I documented this uncertainty in my choices.txt.

[Daniel Simpson]

Originally posted by Frank Verbruggen:
When name/location pair is already known in the database,
of when all fields (except the "booked" field) match the input.

This is very unclear to me since NOTHING in the DB file specifies name/location as the key for a record !

Frank, there has been much discussion on this topic, and some have felt that there needs to be some sort of unique key field in order to throw it. I actually took the opposite approach and a DuplicateKeyException was thrown if all the record's values (except customer id, don't check that one) were identical to the newly created record after trimming the record values. If so, then a DKE is thrown. I documented my decision and didn't get anything taken off because of it. It's really up to you.

[Reza Rahman]

Frank:

I'm checking on name/location only and justifying my decision. I think this is closest to what would happen in the real world if you had an incomplete specification.

In my opinion, checking all of the fields is straying too far from the concept of keys. Except for very small records, this is not too realistic. I don't think the sample database given to us by Sun supports this hypothesis too well either.

Then again, I think the point of the exam is the thinking through the problem and documenting your thoughts part, not the ultimate solution.

Reza

[peter wooster]

Originally posted by Reza Rahman:
Frank:

I'm checking on name/location only and justifying my decision. I think this is closest to what would happen in the real world if you had an incomplete specification.

In my opinion, checking all of the fields is straying too far from the concept of keys. Except for very small records, this is not too realistic. I don't think the sample database given to us by Sun supports this hypothesis too well either.

Then again, I think the point of the exam is the thinking through the problem and documenting your thoughts part, not the ultimate solution.

Reza

I don't throw it based on the choice that a true duplicate for a room would require Location, Name, Date and RoomNumber to be identical. And room number is not currently part of the data.

[Frank Verbruggen]

So in the end, most of all the solutions are good, as long as u justify yourself in the choices file.
Thanx all