B&S: DuplicateKeyException?

[Ewan Livingstone]

Okay, so a method in the interface DBMain is defined thus in my spec:

// 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;

My issue is this: in what circumstance should DuplicateKeyException be thrown? There is no ID/key argument - the implementation must, therefore, either find a deleted record and overwrite, or expand the DB file by creating a new record at the end. Either way, I don't see any way in which there could ever be any circumstance in which one cannot insert a record because the ID/key already exists.

Am I missing something?

[Jim Petersson]

I chose to use name + location as a primary key. Of course this has to be mentioned in the choices file. I guess this is one of those cases were you need to make a design decision for yourself.

[Jens Voss]

I am not throwing a DuplicateKeyException at all in my implementation because I use the recNo (i.e. the record's position in the db file) as the primary key.

The alternative would have been a compound key consisting of the contractor name and location, but in that case the declaration of the update() method would be problematic because updating the primary key field could also cause a uniqueness violation; however the method does not declare that Exception (at least not in my B&S version (2.1.1)).

In contrast to that, the recNo of a record never changes because I don't physically delete records but just set them to "logically deleted" via the deleted flag.

Regards,
Jens

[Joshua Fix]

I just call my find(String[]) method on the data that was passed in to the create method. It in turn attempts to match every field of a record to the fields of the record that is trying to be created.

If any matches are returned, then there is an entry with all the same values. In that case, I throw a DuplicateKeyException.

[rinke hoekstra]

Originally posted by Jim Petersson:
I chose to use name + location as a primary key. Of course this has to be mentioned in the choices file. I guess this is one of those cases were you need to make a design decision for yourself.

Supposing you are talking about urlybird:
I wouldn't do that. What makes you think that each hotel just has exactly one room to offer? I didn't think that very likely. It is more likely that, when a hotel is a customer of urlybird, they may have several rooms in the offering, and two rooms may even have exactly the same field values. Why shouldn't a hotel have two rooms available on the same date, both non-smoking, for the same price?

[rinke hoekstra]

Originally posted by Joshua Fix:
I just call my find(String[]) method on the data that was passed in to the create method. It in turn attempts to match every field of a record to the fields of the record that is trying to be created.

If any matches are returned, then there is an entry with all the same values. In that case, I throw a DuplicateKeyException.

Again: why shouldn't hotel "Palace" in "Sometown" have two (or more) rooms in the offering on the same date, for the same price, and both non-smoking? It's a hotel, so they're expected to have many rooms available!

I think the only valid key is the record number. There is no reason to say that two records are not allowed to have all fields equal.
[ June 25, 2008: Message edited by: rinke hoekstra ]

[rinke hoekstra]

Originally posted by Ewan Livingstone:
I don't see any way in which there could ever be any circumstance in which one cannot insert a record because the ID/key already exists.

Am I missing something?

No, you're not missing anything. You phrased it perfectly: there is not any circumstance in which one could not insert a record because the key already exists. So, this exception is completely bogus. Just ignore it. But don't forget to put it in your choices why you ignore it.

[Joshua Fix]

Again: why shouldn't hotel "Palace" in "Sometown" have two (or more) rooms in the offering on the same date, for the same price, and both non-smoking? It's a hotel, so they're expected to have many rooms available!

I think the only valid key is the record number. There is no reason to say that two records are not allowed to have all fields equal.

I am working on B&S. For me, it seemed too unlikely that two businesses with the same name are in the same city that offer the same specialties and have the same number of employees and same rate.

I haven't read too much about the other exams, but for the B&S, it makes sense to me that you would never have two records with all identical fields.

[Soroj Margun]

Hi all,

This is one of many ambiguous things in the spec. that you have to cope with. There are many solutions for this but only one thing that I want to recommend is whatever you choose, do not forget to write down the reason in choice.txt

Wish you all pass

[Jim Petersson]

Originally posted by rinke hoekstra:


Supposing you are talking about urlybird:
I wouldn't do that. What makes you think that each hotel just has exactly one room to offer? I didn't think that very likely. It is more likely that, when a hotel is a customer of urlybird, they may have several rooms in the offering, and two rooms may even have exactly the same field values. Why shouldn't a hotel have two rooms available on the same date, both non-smoking, for the same price?

No I'm doing B&S. However after reading Jens previous post about the problems it will lead to in the update method I've decided not to throw this exception at all.
Thanks for pointing out the update-problem Jens! I had not thought about that
[ June 26, 2008: Message edited by: Jim Petersson ]

[rinke hoekstra]

Originally posted by Joshua Fix:


I am working on B&S. For me, it seemed too unlikely that two businesses with the same name are in the same city that offer the same specialties and have the same number of employees and same rate.

Hi Joshua,

sure, I was talking about URLyBird. I don't know the specs of B&S.