aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes No definition of what is a DuplicateKeyException Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "No definition of what is a DuplicateKeyException" Watch "No definition of what is a DuplicateKeyException" New topic
Author

No definition of what is a DuplicateKeyException

Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
Hi ranchers,

I stumble upon this particular DuplicateKeyException. There seems like there is no instruction of what it should do anywhere in the instructions.html document.

----------------------------------------------------------------------------

Below is my DBAccess interface:



After all the code, the following two paragraphs:

Any unimplemented exceptions in this interface must all be created as member classes of the suncertify.db package. Each must have a zero argument constructor and a second constructor that takes a String that serves as the exception's description.

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.

----------------------------------------------------------------------------

It did not says what this DuplicateKeyException should do at all. The only method that throws this exception only accept the record values, it does not accept a "key" at all. If The "Key" should be one of the record values, then one of the record values should be a primary key, but the record values are not eligible to be a primary key at all.

Thanks in advance for anyone who answers my doubt.
[ May 25, 2004: Message edited by: Clivant Yeo ]

Clivant Yeo
My Personal Website
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
I used the row number that the record located in the database file as the primary key of the record.

In such sense, the DuplicateKeyException will never be thrown, becos:
1. when you add a new record, it always append to the database file, and thus, the key will not be duplicated
2. if you have deleted a record, and add one new record, the newly added record will replace the deleted record, and thus, the key will not be duplicated as well.

Since the instructions do not clearly specified what should be the key, and thus, you can feel free to make any assumptions, but just, rememeber to write it down in your design documentation.

Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
Thanks Nicholas,

So does it mean that I still perform a check on the record number to see if it is duplicated even though I know that duplicacy will never occur?

Clivant
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
There isn't anything mentioned about the DuplicateKeyException in my specs also.(BS assign) except for the method signature in the DB interface. I have assumed Name,Location fields to be the primary key in my application, as it makes more sense to me.

In the create method() I am searching thru all the records in the database file.If a record of the same primary key exists, then I throw DuplicateKeyException(a checked exception).I also note down the record number of the first deleted record that I come across, so that I can insert the record later at that position.If I do not find any deleted record, then I add the record to the end of the file.
Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
Hi Vishwa,

If you says that the name and locality forms a primary key and if it got duplicated, DuplicateKeyException gets thrown, but wouldn't the update method can have that occurance too? However, why do the update method does not throw this exception?
Steven Hoodless
Ranch Hand

Joined: Mar 23, 2004
Posts: 64
Clivant,

In the URLyBIRD test you can feasibly argue in your documentation that duplicates are acceptable. The same hotel in the same town could be renting two rooms on the same day to the same customer. Both are non-smoking and hold the same number of guests.

You can safely argue that until the customer (in the dim and distant future) requires room numbers per record there is no requirement for a duplicate key check.

Steven


SCJP, SCJD, SCWCD.
Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
Hi Steven,

My scenario here is not about booking hotel rooms but booking contractors for home furnishing and etc. I am caught in this DuplicateKeyException because it's purpose is not stated in the instructions.

If it is something related to the record values, both the createRecord() and updateRecord() method in the DBAcess interface (look at my first posting) should be declared to throw the DuplicateKeyException. But only the createRecord() method is being declared to throw it and not the update() method.
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
Originally posted by Clivant Yeo:
If you says that the name and locality forms a primary key and if it got duplicated, DuplicateKeyException gets thrown, but wouldn't the update method can have that occurance too? However, why do the update method does not throw this exception?


Clivant,
I agree. That's a good question. Yes. It is possible for the update() method to violate the primary key constraint and make the database go into an inconsistency state.I intend to document in my choices.txt that Since the DuplicateKeyException is missing in the update() method signature and not much information is given about the primary key constraints in the specs, my update() method would not allow the updation of primary key fields. I would throw a RuntimeException with a message, if any attempts to update the primary key fields are made in the update() method.

There's been some interesting discussion in the following threads, mentioned in one of Phil's old posts.

http://www.coderanch.com/t/184254/java-developer-SCJD/certification/DuplicateKeyException

http://www.coderanch.com/t/183894/java-developer-SCJD/certification/NX-Duplicate-Key-when-updating

http://www.coderanch.com/t/183817/java-developer-SCJD/certification/Nx-Documenting-DuplicateKeyException
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

So does it mean that I still perform a check on the record number to see if it is duplicated even though I know that duplicacy will never occur?

YES. I have done the checking, but I know it is impossible to happen.



Nick
Vishwa Kumba
Ranch Hand

Joined: Aug 27, 2003
Posts: 1064
I am doing the BS Assign and I wanted to keep the concept of primary key simple.

BTW, My update() method allows the record to be updated with primary key fields, if the record is deleted.Similarly create() method allows deleted records with the same primary key fields to be added again. (I am treating deleted records as records that do not exist in the database, my specs say that)
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982

If you says that the name and locality forms a primary key and if it got duplicated, DuplicateKeyException gets thrown, but wouldn't the update method can have that occurance too? However, why do the update method does not throw this exception?

Since the name and location can be duplicated, this combination is not a good idea to be the primary key.

Anyway, no matter which primary key to be chosen, you need to write down the assumption, and why you make such decision. I guess, any reasonable assumptions is ok.

Nick
Baruch Sadogursky
Ranch Hand

Joined: Apr 09, 2002
Posts: 62
I have a big problem with the update() method, which doesn't throw the damn exception... Invent some RuntimeException while DuplicateKeyException exists seems somewhere ugly to me. I ignore it for meanwhile, but have opened a Thread in mind...


Regards,<br />Baruch.<p>SDFWOF<br />FGEHWS<br />FNEVGE
Ronnie McBob
Greenhorn

Joined: Sep 09, 2004
Posts: 12
Hi guys,

I was reading the earlier posts on the DuplicateKeyException issue and there were some arguments for just not using a primary key...

However, it appears as if people are no longer discussing this as an option. Is this because somebody has tried this and it was deemed to be the "wrong" (sub-optimal) option?

There was a posting where somebody had said that they used a primary key and they received full marks. Is this why everybody is now only considering the use of the primary key?

Thanks,

Ronnie
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ronnie,
I was reading the earlier posts on the DuplicateKeyException issue (...)

There was a posting where somebody had said that (...)

Could you be more precise? It could help us replying if you gave us the links to the threads/posts you're referring to.
If you don't know how to include such links in your posts, it's explained here (UBB codes descrption).

Regards,

Phil.
[ September 11, 2004: Message edited by: Philippe Maquet ]
Clivant Yeo
Ranch Hand

Joined: May 22, 2004
Posts: 124
Hi,

I implemented the method but did not declare it to throw the DuplicateKeyException. Since it's puropose is not stated, and exceptions thrown in the super class need not be thrown in the subclass, hence i will just state an assupmtion in my choices.txt that the people responsible for creating or updating the records will ensure that there is no record duplicacy.

Further more, there is no "must" that i must provide for the creation, updation and deletion of records, hence, i implemented those methods but did not use them.

I only need a record booking function and two search functions, therefore, i created another method called bookRecord that only update one field instead of using the heavyweight updateRecord method.

Rgds
Clivant
Ronnie McBob
Greenhorn

Joined: Sep 09, 2004
Posts: 12
Philippe,

The links that I was reading came from this posting:

http://www.coderanch.com/t/186132/java-developer-SCJD/certification/two-cents-duplicateKey-Exception

There are 3 further links in this posting that appear to summarise much of the discussion on the topics of primary key and how to deal with the DuplicateKeyException.

I think you were quite involved in some of the posts.

Thanks,

Ronnie
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ronnie,
I think you were quite involved in some of the posts.

You know my opinion on the topic then...
I didn't reread all those links, but I remember that I was in favor of implementing optional support for primary keys, justifying my choice by Data reusability. I'm less sure today that it's useful (trying to make Data reusable), and in case:
  • you wouldn't care about reusability
  • there is no "natural" primary key in you Data file
  • , I wouldn't throw DuplicateException from your implementation, but just keep it in the interface.

    Regards,

    Phil.
    [ September 12, 2004: Message edited by: Philippe Maquet ]
    Andy Zhu
    Ranch Hand

    Joined: May 26, 2004
    Posts: 145
    DuplicateKeyException is also bothering me in the 2 points:

    1. From the point of db, create and update should both apply the same rule for uniqueness, which to me, it implies both should throw the ex. However, the interface per se is inconsistent. If you handle some duplicate cases in create, how do you handle it in update? (I don't think this ex should be extended runtime ex; we should enforce to catch it and handle it in calling method.)

    2. In my assignment and in many other previous posts, it is clear that there may not be any specific fields suitable for primary key (it is not in my assignment). However, from db theory, a primary key should not be null. therefore a null-validation is a candidate for dup ex. furthermore, a null value for name and location provide no information to a modifying record, which should be another candidate for dup ex.

    This is my consideration for dupex. But now my question is how I can handle it in update: I want to keep it consistent with create. Any suggestion/comments?


    --------<br />Andy Zhu<br />scjp 1.4<br />scjd 1.4<br />SAS Certified Programmer 9.0
    Clivant Yeo
    Ranch Hand

    Joined: May 22, 2004
    Posts: 124
    Hi Andy,

    My suggestion is not to throw the DuplicateKeyException at all.

    Firstly, it is defined in the interface, which means that the subclass can choose not to throw it.

    Secondly, the specs (for my case at least) does not state its purpose and the documentation of the method that throw the DuplicateKeyException does not state something like "throw DuplicateKeyException when blar blar blar occurs".

    Thirdly, the specs (for my case at least, again) does not require the program to provide updation, creation or deletion of records.

    With the three justifications, I implemented my update and create method without throwing the DuplicateKeyException, which makes the two methods consistent. I later state an assumption that the people responsible for creating and updating records (if possible), will check the uniqueness of the records. I have not hand up my project though, maybe I am going to hand it up before the end of this month. (Trying to get myself mentally and financially prepared first).

    Just my two cents of opinions.

    Rgds
    Clivant
    Andy Zhu
    Ranch Hand

    Joined: May 26, 2004
    Posts: 145
    Hey, Clivant:

    Thanks for your reply. Yes, not to throw dupex is an option. But how do you check null values and how do you handle it when they are null in your create and update? As I can think of, these are the case eligible for dupex.
    Clivant Yeo
    Ranch Hand

    Joined: May 22, 2004
    Posts: 124
    Hi Andy,

    Let's say you have a String input that you get from the user as an input.

    You can check for nul value by having a test case like this:

    if(input.trim().length()==0) {
    //input is null, warn user
    }

    Hopes that answer your query.

    Rgds,
    Clivant
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: No definition of what is a DuplicateKeyException