No definition of what is a DuplicateKeyException

[Clivant Yeo]

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:

 package suncertify.db;
public interface DBAccess
{
// Reads a record from the file. Returns an array where each
// element is a record value.
public String [] readRecord(long recNo)
throws RecordNotFoundException;
// Modifies the fields of a record. The new value for field n 
// appears in data[n]. Throws SecurityException
// if the record is locked with a cookie other than lockCookie.
public void updateRecord(long recNo, String[] data, long lockCookie)
throws RecordNotFoundException, SecurityException;
// Deletes a record, making the record number and associated disk
// storage available for reuse. 
// Throws SecurityException if the record is locked with a cookie
// other than lockCookie.
public void deleteRecord(long recNo, long lockCookie)
throws RecordNotFoundException, SecurityException;
// Returns an array of record numbers that match the specified
// criteria. Field n in the database file is described by
// criteria[n]. A null value in criteria[n] matches any field
// value. A non-null  value in criteria[n] matches any field
// value that begins with criteria[n]. (For example, "Fred"
// matches "Fred" or "Freddy".)
public long[] findByCriteria(String[] criteria);
// 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 long createRecord(String [] data)
throws DuplicateKeyException;
// Locks a record so that it can only be updated or deleted by this client.
// Returned value is a cookie that must be used when the record is unlocked,
// updated, or deleted. If the specified record is already locked by a different
// client, the current thread gives up the CPU and consumes no CPU cycles until
// the record is unlocked.
public long lockRecord(long recNo)
throws RecordNotFoundException;
// Releases the lock on a record. Cookie must be the cookie
// returned when the record was locked; otherwise throws SecurityException.
public void unlock(long recNo, long cookie)
throws SecurityException;
}

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 ]

[Nicholas Cheung]

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

[Clivant Yeo]

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]

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]

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]

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

[Clivant Yeo]

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]

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.

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

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

https://coderanch.com/t/183817/java-developer-SCJD/certification/Nx-Documenting-DuplicateKeyException

[Nicholas Cheung]

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.

public ... update(...) throws DuplicateKeyException {
  if (duplicate) {
    throws new DuplicateKeyException(msg);
  }
 
  do the update
}

Nick

[Vishwa Kumba]

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]

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]

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...

[Ronnie McBob]

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]

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]

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]

Philippe,

The links that I was reading came from this posting:

https://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]

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]

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?

[Clivant Yeo]

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]

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]

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