Meaningless Drivel is fun!*
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


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "DuplicateKeyException" Watch "DuplicateKeyException" New topic
Author

DuplicateKeyException

Manoj Dixit
Ranch Hand

Joined: Sep 13, 2003
Posts: 31
Hello all,
I have read almost all threads regarding �DuplicateKeyException� of create method. Some suggested using �Name+Location� as primary key and some says just leave it.
I am really confused because instruction doesn't say anything about it.
please let me know what to do?.
The method has following signature (Bodgitt and Scarper).
// creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create (String[] data) throws DuplicateKeyException;
Manoj,
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi Manoj
I am glad to see that I am not the only one that is a little confused about this. Currently I have set it up to only throw a DuplicateKeyException exception if an IOException occurs. The assignment does not state anything about primary keys. You are right that it is possible to use the name and location but is that enough?
IMO the whole DM has a big fault. Say you want to book a contractor that has the skill set of "Roofing, Painting" to do a small roofing job that took only one of the eight staff to do. You would fill in the booking field. Then you wanted to book the same contractor to do a small painting job, what do you do? The contractor has enough staff and the skills to do the job but you can not book them because they are already booked on the roofing job.
The way to get around this would be to have two different records in the DB for the same contractor but with different skills. However doing so takes away the possibility of using name and location as the key.
This is a thread I am going to be keeping a close eye on.
Chris


SCJP 1.2, SCWCD, SCBCD
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Here's my two cents.
Think simple. Wow, I have never said that before.
All your points are accurate in the real world.
However, this is the simple world of SCJD. Just imagine that in the SCJD world that one contractor can only do one thing at a time, but they have lots of skills. Yes they have eight employees., and the one day job is only going to take one employee, but don't think too far into that. or you will dirve yourself crazy. It is a one to one relationship, you book the entire company, or none in the company. You shouldn't have two entries because they can do two different types of work.
And you can put that in your design decisions document, and point out that you make name and location the Primary key, and you are good to go.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi Mark,
Thanks for the advice. I think I am going to use the name and location as a primary key and make a note in choices.txt about the issues I have with the DB.
I suppose this type of thing is what choices.txt is for.
Chris
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
IMO the whole DM has a big fault.
Oh, it has a number of faults. The lack of any dates is another big one. "I'm sorry, that contractor has already been booked." "Well, how about the next week?" "No, he's just booked, well, forever. Try someone else." :roll:
Anyway - "keep it simple" can also be used to justify not writing any code at all to enforce any unique primary key, since there's no actual requirement to do so. (In my instructions at least.) The lone line "throws DuplicateKeyException" just means that you could throw a DuplicateKeyException; there's no requirement to actually do so, and no real info about what that key should be. (Though name + location seems like a pretty good guess.) And the GUI has no ability to create new records anyway, or edit the name/location fields, so even if name + location is a key, it's not going to matter in our application. My documentatin makes clear that this was an ambigous issue that should be resolved with B&S before any further enhancements are made which might depend on whether or not DuplicateKeyException might realy be thrown or not.
This is another issue that you can go either way on really, depending on how you interpret the specs, or what assumptions you want to make on how the DB class might be used in the future. I'm just offering one alternate view...


"I'm not back." - Bill Harding, Twister
Chris Harris
Ranch Hand

Joined: Sep 21, 2003
Posts: 231
Hi,
Talking about Exception that are throw in the Data class, is anyone actually throwing RecordNotFoundException on the lock and unlock methods? As I do not cache the Records this will lead to unnecessary reads of the DB.
Chris
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Talking about Exception that are throw in the Data class, is anyone actually throwing RecordNotFoundException on the lock and unlock methods?
Yep. In my requirements it's explicitly required. "Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."
As I do not cache the Records this will lead to unnecessary reads of the DB.
They're not quite unnecessary, but they are annoyingly inefficient. It was thinking about this issue that led me to more strongly consider a full-caching solution.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Manoj,
If I put aside Chris who is waiting for an advice as you are, you just got two different advices :
  • Mark : Keep it simple ( ), yes "Name" + "Location" make a good candidate for a unique key (and justify it)
  • Jim : forget about the unique key issue because the instructions are not clear enough (and justify it)


  • I am afraid I'll just add some confusion, but here is what I did :
    In URLyBird (with the same DuplicateKeyException thrown in createRecord()), it's impossible to even imagine some unique key with the fields we are given.
    So I hesitated between "forget it and justify why" (2) and "implement a possible solution which fulfills the requirements" (3).
    OOH, I didn't dare solution 2, and OTOH, as I designed my DB tier quite independandly of URLyBird (e.g. URLyBird uses one table but my DB layer is multi-table by design), I decided to implement in Data an optional primary key, which the assignment doesn't use (3).
    Best,
    Phil.
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Chris,
    Talking about Exception that are throw in the Data class, is anyone actually throwing RecordNotFoundException on the lock and unlock methods? As I do not cache the Records this will lead to unnecessary reads of the DB.

    Even if you don't cache the database, think of caching the deleted records (a simple HashSet deletedRecNos would do the job). createRecord() would be happy to have it at hand, but all methods throwing RecordNotFoundException would be happy too, just to be able to call a fast isDeleted(long recNo) method when needed.
    Best,
    Phil.
    Manoj Dixit
    Ranch Hand

    Joined: Sep 13, 2003
    Posts: 31
    Thanks,
    Mark,Philippe,Chris and Jim for making things more clear.
    Here, what I am planning:
    private boolean (String[] primary){
    //create method will call this method.
    //It will check for duplicate "Name+Location".

    Manoj,
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Manoj,
    //It will check for duplicate "Name+Location".

    If you don't apply Jim's solution (forget and justify it - which is very defendable IMO), please don't "force" a primary key. It doesn't make any sense : "Name+Location" are not said unique in your instructions and are not unique in the business you are building a software for ...
    Best,
    Phil.
    Manoj Dixit
    Ranch Hand

    Joined: Sep 13, 2003
    Posts: 31
    Hello Philip,
    If you don't apply Jim's solution (forget and justify it - which is very defendable IMO), please don't "force" a primary key. It doesn't make any sense : "Name+Location" are not said unique in your instructions and are not unique in the business you are building a software for ...

    Frankly, I did not understand what you are suggesting.
    Can you please explain what is wrong with the method I mentioed earlier.

    Manoj.
    Philippe Maquet
    Bartender

    Joined: Jun 02, 2003
    Posts: 1872
    Hi Manoj,

    Hello Philip,
    quote:
    --------------------------------------------------------------------------------
    If you don't apply Jim's solution (forget and justify it - which is very defendable IMO), please don't "force" a primary key. It doesn't make any sense : "Name+Location" are not said unique in your instructions and are not unique in the business you are building a software for ...
    --------------------------------------------------------------------------------
    Frankly, I did not understand what you are suggesting.
    Can you please explain what is wrong with the method I mentioed earlier.

    I'll try. The DuplicateKeyException issue in createRecord is this :
  • DuplicateKeyException is explicitly thrown by createRecord()
  • Nowhere in the instructions you may find any definition of what should or could make some unique or primary key.
  • Worst, updateRecord() doesn't throw any exception in case the primary-unique key is modified in such a way that the unique constraint is not respected.


  • Given that issue, you have 3 possible solutions :
  • Implement the check and decide that some fields make a unique combination (example "Location" + "Name") : it's what Mark suggested. If you do, make sure that it makes sense to force the fields you choose to be unique (in URLyBird, it's impossible), and find a solution for the updateRecord() method (think of IllegalArgumentException).
  • As Jim suggests, conclude that we don't have enough information to correctly implement a unique / primary key constraint and ... do nothing (but justify it).
  • As I did, try to "invent" a possible implementation of that unique / primary key constraint, and make it optional at the table level.


  • I hope it's more clear (but I am quite unsure of it ).
    Best,
    Phil.
    [ September 29, 2003: Message edited by: Philippe Maquet ]
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: DuplicateKeyException
     
    Similar Threads
    DuplicateKeyException
    B&S: DuplicateRecordException
    NX: Question about create()
    Question about DBMain interface
    nx: All of URLy Bird 1.1.3 read/write lock(2)