DuplicateKeyException

[No�l Verdurmen]

In my assignment the create method throws a DuplicateKeyException. However, I find it hard to say what the primary key is.

My thinking is to take a record number as a primary key. Is that valid?

Choosing the name and/or location as primary key seems inappropriate to me. Isn't it possible that there are more free rooms in the same hotel?

[Hanna Habashy]

Noel,

My thinking is to take a record number as a primary key. Is that valid?

Record number is never a valid primary key. Record primary key must be unique, and invariant. I mean by that the record primary key must not change because the record position changes for any reasons such as ordering the database records. The uniqueness comes from a unique data elements or peoperites about this specific entity. Properties that no other enitiy could have.
There is must be something uniquely identify your individual record, you have to find it..
[ August 23, 2004: Message edited by: Hanna Habashy ]

[mike acre]

Originally posted by No�l Verdurmen:
In my assignment the create method throws a DuplicateKeyException. However, I find it hard to say what the primary key is.

My thinking is to take a record number as a primary key. Is that valid?

Choosing the name and/or location as primary key seems inappropriate to me. Isn't it possible that there are more free rooms in the same hotel?

If you have the same fields in your UyB as me and I think everyone does.
Then the only primary key is the physical record number.
Since the physical record number is impossible to duplicate, a DuplicateKeyException will never be thrown by UyB.
However the inteface and indeed implementation of it may well be useable by databases that can throw DKE, so I'd keep the recognition of this fact to choices.txt

[No�l Verdurmen]

Thanks for your quick reply, Hanna

Record number is never a valid primary key. Record primary key must be unique, and invariant.

Hmm.. that was exactly where I was afraid of. I guess I have to come with something better.
[ August 23, 2004: Message edited by: No�l Verdurmen ]

[mike acre]

Originally posted by Hanna Habashy:
[QB]Noel,

Record number is never a valid primary key. Record primary key must be unique, and invariant. I mean by that the record primary key must not change because the record position changes for any reasons such as ordering the database records.

This I will concede, you are correct.

The uniqueness comes from a unique data elements or peoperites about this specific entity. Properties that no other enitiy could have.
There is must be something uniquely identify your individual record, you have to find it..

This is not correct.

There is no requirement for a primary key at all.

And if you are not familiar with UyB, then there very arguably is not.

[Hanna Habashy]

Mike,

And if you are not familiar with UyB, then there very arguably is not.

YOu are right, I am not familiar with UyB. However, I am not discussing a specific project, I am discussing averall database design.

[No�l Verdurmen]

Mike,

I was more or less thinking the same. The record number is fixed in my application, so I won't have the problem that my primary key changes.

But what still wonders me is why that DuplicateKeyException is in the specified create() method? There must surely be an elegant solution?

Well.... I think I'm going to keep the record number as my primary key after all

[mike acre]

But what still wonders me is why that DuplicateKeyException is in the specified create() method? There must surely be an elegant solution?

Because who knows what that interface is used for.
The whole point of an interface is that there are multiple implementations, not just yours.

An elegant solution is recognising that there is no primary key, and documenting that fact and that DKE will never be thrown. There is no requirement that an interfaces Exceptions should be thrown. An interface merely outlines a specification that considers it is reasonabel to expect it to be thrown. Normally this would be very reasonable, as Hanna has said a table should normally have a primary key, but it isn't a requirement, and in this case there clearly is not. If every field can not make a unqiue key, then there is not a unique key.
Hanna is quite correct, the physical recNo can not be taken as primary key since reordering could cause that to change.

[Anton Golovin]

Hi, Mike! I throw the DuplicateKeyException. I do in for the physical record number (which is also the logical record number in my cache.) If I am creating a record, I find out a "deleted" record (I have a TreeSet that keeps the numbers), check if it exists in the cache, and if it does, I throw a DuplicateKeyException. If the deleted list is empty, I figure out the record number to assign to the new record, then check it against the keys in my HashMap (the cache), and if a duplicate exists, I throw the exception. Maybe it is not what they are looking for, but I need to throw something there. Of course, I will document the fact that it should never really be thrown in the control flow. The problem for me was that I use io facilities in the method as well (to write reused record to disk before committing it to the cache.) create method must return an integer, and can only throw DuplicateKeyException - not by any means a good wrapper for an IOException. So my method returns -1 for any error conditions.
[ August 23, 2004: Message edited by: Anton Golovin ]

[Paul Bourdeaux]

There is no requirement for a primary key at all.

I have to agree with Hanna, it is not very good design to have a database without a primary key. Granted, I conceed that I am not familiar with the UyB requirements either...

[peter wooster]

Originally posted by Anton Golovin:
Hi, Mike! I throw the DuplicateKeyException. I do in for the physical record number (which is also the logical record number in my cache.) If I am creating a record, I find out a "deleted" record (I have a TreeSet that keeps the numbers), check if it exists in the cache, and if it does, I throw a DuplicateKeyException. If the deleted list is empty, I figure out the record number to assign to the new record, then check it against the keys in my HashMap (the cache), and if a duplicate exists, I throw the exception. Maybe it is not what they are looking for, but I need to throw something there. Of course, I will document the fact that it should never really be thrown in the control flow. The problem for me was that I use io facilities in the method as well (to write reused record to disk before committing it to the cache.) create method must return an integer, and can only throw DuplicateKeyException - not by any means a good wrapper for an IOException. So my method returns -1 for any error conditions.

[ August 23, 2004: Message edited by: Anton Golovin ]

Just because the interface provides for the throwing of an exception, there is no need to actually throw it. Here you are confusing "necessary" and "sufficient". Just because the interface provides the DKE doesn't mean it requires it. Inconsistencies between the actual data and your cache are not a good use of DKE. To get a DKE you must have a real primary key. In the UrlyBird there is no ability to provide a primary key. The obvious PK is Name,Location,Room,Date. Since Room is not in the database there is no ability to define a primary key, so no DKE.
[ August 23, 2004: Message edited by: peter wooster ]

[Anton Golovin]

Originally posted by peter wooster:



Just because the interface provides for the throwing of an exception, there is no need to actually throw it. Here you are confusing "necessary" and "sufficient". Just because the interface provides the DKE doesn't mean it requires it. Inconsistencies between the actual data and your cache are not a good use of DKE. To get a DKE you must have a real primary key. In the UrlyBird there is no ability to provide a primary key. The obvious PK is Name,Location,Room,Date. Since Room is not in the database there is no ability to define a primary key, so no DKE.

[ August 23, 2004: Message edited by: peter wooster ]

I am probably confusing things. I am throwing the DuplicateKeyException because the primary key in my cache is the record number. I can prove it: each record number is unique. Maybe I misunderstand something. If it can't be done, then I won't do it - but so far, it looks like there is a primary key which should not be duplicated when a new record is created.

[Robert Konigsberg]

I am probably confusing things. I am throwing the DuplicateKeyException because the primary key in my cache is the record number. I can prove it: each record number is unique. Maybe I misunderstand something. If it can't be done, then I won't do it - but so far, it looks like there is a primary key which should not be duplicated when a new record is created.

Eh, that's not a key, though. Keys are attributes of records. If your assignment is B&S, there is a possibliity that you have no primary key at all, and that while you assignment requires that your method has a "throws DuplicateKeyException" clause, you might not actually do it.

Rob

[Olivier Dumont]

Mike:
An elegant solution is recognising that there is no primary key, and documenting that fact and that DKE will never be thrown. There is no requirement that an interfaces Exceptions should be thrown.

I think Mike is right. (As Peter and Robert later in the thread BTW)

Searching on this forum, I could find this link which in turn includes a few other links on the same topic.

Hope this helped.

Regards,

Olivier.
[ August 24, 2004: Message edited by: Olivier Dumont ]