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

NX: Any thoughts on DuplicateKeyException (URLyBird)

 
Lance Ewing
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm sure the answer to this question is not giving away too much. My assignment has a DB interface that must be implemented. It has a create() method that throws a DuplicateKeyException but no information that I have found yet for when this exception might be thrown. The format of the database file is such that there don't appear to be any fields that are unique keys (even combinations of fields), and the data provided to the create() method does not appear to provide a key of any kind. From first, second, and third appearances it looks as if all that is provided to the method is the record data (with no keys as such) and it will simply create a new record no questions asked every time it is invoked. So where would a duplicate key ever be encountered? Am I missing something?
Those who are working on URLyBird (1.3.3) will be able to see what I mean and are possibly the only ones who could answer this question. At first I thought that the 'name' field might be unique, but I am now certain that there can be more than one record with the same value for the name field, infact there could be a great number with the same value. I started looking at combinations of fields to present the primary key, but it appears based on the field descriptions and application description that it could even be possible to have more than one row with exactly the same values for all of the fields (strange as it seems, but I see no reason at present based on the nature of the application why it would introduce a problem to have two identical records). All I can go by is the DB interface provided, the description of the fields, and the intended use of the application. So at this stage I'm thinking I do not need to ever throw the exception.
 
Anna Hays
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In future expansion, your program might need to allow user to specify their own key (usually PK). Specifying your own key is very common. That is my only thought.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Lance,
Welcome to JavaRanch!
You're right that with all versions of the URLyBird assignment, there is no way to make any key unique.
That issue was discussed a lot in the past I think. Try
this link (and the links included ).
Regards,
Phil.
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Here is one of Phil's responses:

I am planning on not throwing the DuplicateKeyException and explaining it in my designchoices.txt.

Looks like reasonable.

-------
And another
------
Originally posted by Philippe MAQUET:

Hi Glenn,
I think it's a perfect approach, as far as you keep DBAccess interface unchanged (!) and don't declare the exception in Data.
Philippe.

[ February 15, 2004: Message edited by: Javini Javono ]
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
From another posting (since these past postings are not always right on topic):

DuplicateKeyException:
I went thru the previous discussion on DuplicateKey..But it was all intermixed interpretations and spiced with little confusion due to different assignments.
But I am quite clear about this and have to throw this exception, as the method signature is:
public int create(String[] data) throws DuplicateKeyException;

I have the same signature. That doesn't say it must be thrown under any particular circumstances, only that it may be thrown by some implementations. Since no details are specified about keys, and the GUI can't create new records anyway, I chose not to spend time writing code for this. You're welcome to do otherwise, and it's certainly possible that B&S really do want you to check for duplicate keys - but they failed to communicate this. It's not a requirement, IMO, merely a reasonable possibility.

-----------------------------------------
Hi,
This is an interesting idea, suggesting that the interface declares it throws
the exception, but the implementation will not.
thanks,
Javini Javono
[ February 15, 2004: Message edited by: Javini Javono ]
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Previous Posts right on topic:
--------------------------------

To clarify, I personally don't advocate adding the exception to the throws clause either. I'm advocating not throwing DuplicateKeyException at all, but leaving it declared in the original interface because of course we can't change that.

-------
This also makes lots of sense.
Thanks
Javini Javono
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi: and another relevant past posting which is directly on topic:
------------
Originally posted by Jim Yingst:
I'd document that the current implementation does not throw any DuplicateKeyException, but it's a possible future enhancement if someone at Bodgitt & Scarper gets off their lazy ass and provides some sort of evidence that the file actually should have a primary key. (And what is it? And what to do about the crappy update() method?)
Well, don't use those words exactly. But do document it, both in the Data API and in the design decisions document.

----------
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Obviously I've applied my own "filters" in grabbing these past responses.
In summary: and you'd have to verify this for your own project, my project
cannot throw a duplicate key exception.
The interface, however, can declare that a DuplicateKeyException is thrown.
But the implementation that I write need not declare that it throws this
exception, and the implementation will compile. The implementation and
other support documents need to document this decision.
Thanks,
Javini Javono
 
Lance Ewing
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There certainly has been a lot of discussion on this as I have just seen from all those links. I'm glad I'm not the only one to encounter this. I am also of the opinion that it isn't currently possible for it to be thrown. I understand the elements of the String arrays to represent the existing fields in the database file, as a number of the method comments state. Since there is no primary key in the database file, there is no way of passing in a primary key to these methods since the String array elements match the existing fields one to one. I guess in the future the database file could change and a key of some sort could be provided, but as all the methods rely on record number to identify a record, I'm not sure what use a primary key would be.

Lance.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic