I am struggling with the DB interaction methods. I found I have to have several assumptions before I write the code.

At first, database record does not have primary key specified (at least not specified in the instructions). Can I assume that the combination of Hotel Name and Hotel Location can uniquely identify a record? In anther word, those two fields could be the primary key of the records. Since the instructions does not say which field(s) I can use as primary key, and the physical position index of the record is not sufficient to be used as a primary key, can I just make the assumption above and specified this assumption in the choice.txt?

Second, data.java is the only interface that application operates underlying database file. This interface has method "create" and "update", which theoretically can assign any kind of values into the fields. I believe the assessors have applications which can automatically try this two methods with different parameters. Can I assume that the parameters are all following the value rule of each field? For example, the "smoking" field should only accept "Y" or "N", anything else is illegal. Do I have to validate the values when they are coming in? Or just make an assumption and leave this issue to the caller side?

Hi Eric, I think you can just use the order of the records in the database file as the primary key. Name and location of the hotel is not sufficient, since a hotel can have many similar rooms, which would violate your primary key. At least in my assignment, the combination of all fields of a record is still not unique enough for a primary key. This is why a simple number (like the order in the file) is the only way to distinguish the records uniquely.

How can you know when will you reuse a deleted record? I believe you have to compare something. Unfortunately, the parameter "data" does not have a room for record index number, it only contains the field such as "hotel name","hotel location", etc. Therefore, I have to find a primary key within the fields so that I can tell whether I should reuse a deleted record or not. And, if I can use a primary key which consists with the data of fields, the DuplicateKeyException makes more sense.

Actually, I just don't reuse any deleted records. My requirements don't say MUST, so I don't do it, which makes life easier. However, if a record is deleted you can just set the deleted flag and don't have to actually delete the data from the file. By this, all indexes are still valid after a delete. During the initial read of the db file I just skip all records that are "deleted" and increment the primary key.