// 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; */ 1. Is it OK not to reuse the deleted entry for new record? I think putting new records append to the end of db file is more simple. 2. When to throw DuplicateKeyException in the createRecord method? It looks the method does not have chance to get duplicated key.
Originally posted by David Chan: // 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; */ 1. Is it OK not to reuse the deleted entry for new record? I think putting new records append to the end of db file is more simple. 2. When to throw DuplicateKeyException in the createRecord method? It looks the method does not have chance to get duplicated key.
Regards, David
If i were you, i would give them what they expect. By their comments for the create method they are expecting to reuse deleted records for new entries. I did the contractor assignment. So i treated the name and location of the contractor as a combined primary key. If the new entry violates this primary key i threw DuplicateKeyException. Arun
1. Is it OK not to reuse the deleted entry for new record? I think putting new records append to the end of db file is more simple.
I agree with Arun, just do it. As a non-english speaker, I understood "possibly" as "if possible". Then someone (Andrew and/or Jim ?) told me that it means "perhaps" or "maybe" ...and it's confirmed by my english-french dictionary. But why would they mention reuse of deleted entries if they didn't expect you to do it ?! Anyway, the requirement is not explicit, so it seems that you may choose not to implement that feature. Yesterday, Vlad wrote in another thread "(an) IT developer MUST strictly follow the specification and only do what is EXPLICITELY required.". It's a design choice per se, probably one of the top main ones.
2. When to throw DuplicateKeyException in the createRecord method? It looks the method does not have chance to get duplicated key.
Hi David! Considering that DB/Data stand for arbitary database files, assuming/defining a implicit primary key which suits the needs for the assignment would be wrong in my opinion. Considering further that DB has no mechanism to define/handle primary key meta data, I'd suggest that the DuplicateKeyException is just reserved for later use. It might only part of the methods signature because client code may be adopted smoother if such functionality is some day provided by DB. What ya thinkin? Regards, Horst.
Also, if you do a search on this forum, you will see many threads on this same question with some very good answers. Pay particular atention to my answers. Just Kidding. Read all opinions and form your own, based on them. Mark
0
