• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: URLyBird 1.2.1, when to throw DuplicateKeyException?

 
Glenn Jones
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please can someone help me out with this problem. My assignment instructions specify that DBAccess#createRecord(String[]) must throw DuplicateKeyException, but it does not specify the conditions under which it should be thrown. The name of the exception suggests that it should be thrown when a client attempts to create a new record that has an identical "key" to an existing record. Assuming that some combination of the record fields constitutes the key, the exception should be thrown when an attempt is made to create a new record for which those fields are identical to an existing record. This seems reasonable, but I have to decide which combination of fields represent the key. Intuition suggests that a hotel room is uniquely identified by the combination of hotel name, city and room number. The problem is that room number is not included in the URLyBird database, which seems like a serious flaw in the database design. It is hard to understand how URLyBird can sell hotel rooms without being able to tell the customer the number of the room, and I can only assume that this is a deliberate mistake. With the current fields it is quite reasonable for two records to have identical fields but still represent different rooms, most hotels will have more than one room that is identical in those terms. For this reason I have chosen never to throw this exception, and I have questioned whether room number is missing from the schema design. Have I missed something obvious or is this a reasonable approach?
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have NX:Contractors, not URLBird. But I came to much the same conclusion - DuplicateRecordException made no sense at all. The concept of key was never defined, and also create() could throw the exception, but not update() - even though update() could change all the fields, whichever ones were part of the key. Except for recNo, but it was impossible to specify recNo during a create(), so it's the program's responsisbility to return a unique recNo, and there's no possibility of a duplicate key (if recNo is the key).
Dunno how relevant that is to your assignment, but my point is that I agree that they may stick an exception in like that which has no logical use, and the best you can do is ignore it.
 
George Fung
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In assingment contractor, recNo is not the key. Anyone lost marks if we don't throw duplicateKeyExcetpoin?
Jim is right. If we throw excetpion in create, we should aslo throw it in update. It seems nonsense in requirement. Any comments, guys?
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I still think it makes perfect sense. In update you should be updating an already existing record, without changing the "Primary" key, and therefore will not create a duplicate key for the database. Wherease create might be sent a record that has the same key and therefore should throw a DuplicateKeyException.
Mark
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have to agree with Mark here. Even though we're really talking about a compound key, it's still a key. Thus, you can run into duplicate key exceptions.
M
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mark,
In update you should be updating an already existing record, without changing the "Primary" key,...

  • How do you enforce that ?
  • A "unique" key should be modifiable, meaning that for coherence a DuplicateKeyException should be declared by updateRecord too - I agree with Jim here


  • As far as URLyBird is concerned - as Glenn said -it's impossible to set any primary/unique key on the supplied DB (no room number).
    So, if we want to implement DuplicateKeyException (after all, Data is a generic class), we could add a primaryKey property (String) and ignore the test is it is null (as in URLyBird).
    But what to do in updateRecord() if the fields corresponding to the key are modified ? Throw a RuntimeException ?
    Regards,
    Philippe.
     
    Mark Spritzler
    ranger
    Sheriff
    Posts: 17278
    6
    IntelliJ IDE Mac Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    This has been discussed before, and while we can't find the exact key in the Hotel reservation assignment, I can say this.
    The interface was designed for a reason. Sun has decided that the exceptions that they throw in their interface are the correct exceptions. If they weren't there would be instructions stating that there might need to be Exceptions added to the interface or implementation class. As I have not heard of any instructions in the instructions.html file. I can reasonable assume that you should not change them.
    I can see a reasonable argument for adding them in the real world. But remember that a big part of the scoring in this cert, is how well you follow directions.
    I will always say, "Do what you want", but know what might be the consequences and to defend your decision in your design/choices document.
    Mark
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic