DuplicateKeyException for update method?

[Reza Rahman]

Has anyone noticed this loophole in the specs?:

1. The create method can throw a DuplicateKeyException.
2. The update method has no DuplicateKeyException thrown.

I am just curious as to if anybody is thinking of handling duplicate keys while updating. Thanks for your input as usual..

[Frank Verbruggen]

The update method could throw the DuplicateKeyException if u made that exception extend RuntimeException.

I myself chose to not throw the exception. Ever.
Because I think that the database does not specify keys,
thus a duplicate key can never exist.

I will document this in choices.txt

But there seem to always be many options, just be sure to document your decisions !
Good luck,


Frank

[Jeff Bosch]

1. The create method can throw a DuplicateKeyException.
2. The update method has no DuplicateKeyException thrown.

Why would you need a DuplicateKeyException for update? You need one for create because you don't want (can't have, actually) two records with the same key. But, with update, you're checking for the existence of the record, then modifying it. I see no chance for a duplicate key in this scenario at all. RecordNotFound... perhaps, but not DuplicateKey...

[Paul Bourdeaux]

I see no chance for a duplicate key in this scenario at all. RecordNotFound... perhaps, but not DuplicateKey...

I could see a scenario. If a user modified an existing record to contain the exact same data as another existing record, then you would now have two duplicate records.

In a real world application, you would definately need to check for this... but for this assignment, it may be outside the scope. I am not checking for it in my assignment, but I am mentioning it in my choices.txt

[Jeff Bosch]

This scenario presumes that the user could modify the key and not just the record. Perhaps in a hash table, but not in a map. I guess it depends on the type of collection and on how you interpret the original question. Because Reza used the word "keys" in the original post, I assumed map, which uses a key-value pair, not a hash which uses a hashing algorithm. I would not permit a user to modify the key, only the value, in a database system such as the one we're given for the exam. The system would generate/modify the key...

[Paul Bourdeaux]

I guess it depends on the type of collection and on how you interpret the original question.

I interpreted "key" to mean a database key, not a key-value pair in a map. More specifically, I was referring to duplicate keys/records in the data file itself. Since it is a flat file instead of a true database, we are left to define our own key (or none at all if we so choose). I am using a RandomAccessFile to access the data, and I decided not to implement a cache.

The way I interpreted the DuplicateKeyException was it would be thrown if two records existed containing the same primary key (which I defined as the entire record). In this case, it is very possible for a user to modify a record so its key matches one that already exists.

[Paul Bourdeaux]

(SCJP 1.4, SCJD in progress, if you can call that progress...)

By the way, great signature

[Jeff Bosch]

The way I interpreted the DuplicateKeyException was it would be thrown if two records existed containing the same primary key (which I defined as the entire record). In this case, it is very possible for a user to modify a record so its key matches one that already exists.

I'm considering doing it a little bit differently by reading the flat file into a collection (probably a form of map with record number as the key) in order to abstract the flat file and remove the need to calculate whether the record is a key or not.

By the way, great signature

Thanks!