File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes DuplicateKeyException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "DuplicateKeyException" Watch "DuplicateKeyException" New topic
Author

DuplicateKeyException

No�l Verdurmen
Ranch Hand

Joined: Jul 28, 2004
Posts: 33
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?


No�l
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
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 ]

SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
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


SCJP 1.4, SCJD
No�l Verdurmen
Ranch Hand

Joined: Jul 28, 2004
Posts: 33
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
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
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
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
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
Ranch Hand

Joined: Jul 28, 2004
Posts: 33
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
Ranch Hand

Joined: Sep 23, 2003
Posts: 197


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
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
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 ]

Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
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...


“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
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
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
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
Ranch Hand

Joined: Jun 23, 2004
Posts: 172

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


SCJP 1.4 (91%)<br />SCJD 1.4 (376/400, 94%)
Olivier Dumont
Greenhorn

Joined: Aug 24, 2004
Posts: 8
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: DuplicateKeyException
 
Similar Threads
Data Integrity is broken
Pimary keys in entity beans
EJBObject for new Entity Beans
Nx: Documenting DuplicateKeyException
B & S App