About DB interface specification I have some questions:
There�s no mention about what field of the record should be defined as a key. The following methods: public int create(String data) throws DuplicateKeyException; public void update(int recNo, String data, long lockCookie) throws RecordNotFoundException, RecordLockedException; public DB.Found find(String key, boolean lock) throws RecordNotFoundException, RecordLockedException;
My consideration is: 1.If I assume the name field is the primary key, then the update() declaration�s throw clause should contains DuplicateKeyException; 2.If it doesn�t require a key field, then the create() will never throw a DuplicateKeyException and the find() methods doesn�t work.
In my current design I choose the second situation to implement. But I still feel a little confused if this meet�s the needs. Is it something error about the specification? Another question: May I use the new v1.4 APIs or not? something like regular express, nio, etc. or I must use v1.4 as my choice only?
There�s no mention about what field of the record should be defined as a key.
I used the name field as the key. The update method should ignore the name field since you are not suppose to change the key of a record, therefore DuplicateKeyException will never be thrown in update, but createRecord will check for duplicate keys and throw DuplicateKeyException. That's just the way I resolved this ambiguity, and you can do it other ways as long as you explain the reasoning behind your choices.
May I use the new v1.4 APIs or not?
I believe you can use anything as long as it will compile and run with 1.4.x [ September 26, 2002: Message edited by: Tybon Wu ]
Joined: Aug 31, 2002
you are not suppose to change the key of a record,
That's my lack of thinking. it's clear now. Thanks for your advice. [ September 26, 2002: Message edited by: Kuanlin Ou ]
Joined: Aug 31, 2002
Well, after a sleep, when I returned the to the questions again, I think my consideration could be reasonable. In OO thinking an object's key(hashcode, id etc., whatever) should be unique and unchangable, but in database world a primary key of a table schema, no matter a single or a combined key, is mutable. therefore a db implementation's update method should take care about duplicated key issues. Anyway I think maybe the assignment doesn't require such function, to simplify the problem I'll implement it just as you advised.
Well, the role of a key in a database is to uniquely identify each record. I don't think that taking the hotel name as the key will be enough since several record may relate to the same hotel name in different locations. This led me to consider taking the name AND location as the key, but again there is no way to ensure that there will only be one hotel with a specific name at a given location. Am I going too far with this?