i have a question concerning the update and search method specified in the Data.java file (DBMain interface).
Database schema: Hotel Name name 64 City location 64 ....
1. create // 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;
Can i assume that there is an array of 8 elements and i have to use the data as follows: data --> Valid record flag (2 characters --> every character is truncated to the size of 1 byte) data --> hotelname (8 characters) data --> city (8 characters)
In my implementation of create from DBMain i have to write the string array as it comes out to for example at the end of the data-file?
Since the user has no possibilty to add a new record do i have to assume that this method is tested automatically?
Now a question at DuplicateKeyException - If i synchronize the creation of an new record on the RandomFileAccess, there is no possibilty that such an exception happens, since the Key of an record is implicit defined through its position in the file?
2. update // Modifies the fields of a record. The new value for field n // appears in data[n]. public void update(int recNo, String  data) throws RecordNotFoundException;
Shoud i assume here the same like at the create method. For example if the array looks like the following description: data --> null data --> null data --> "Vienna" data --> null ....
i have to update the specified record and change only the name of the city. (Sure this is not possible through the GUI but that's my interpretation of this Data-interface)
or another interpretation is, that all parameters have to be given for example: data --> [VALID_RECORD_COOKIE] data --> Excellsior data --> N.Y. data --> ... ..... and i have to write all fields to the record.
The specification is not clear about this, and i know to make a free implentation if a can argument my decisision. But since the this interface is very well defined and i must implement it, i'm scared that a test of my implementation is part of the automated test.
I guess the answer to the first part of your question is to question whether can we have two exact same records with just different record numbers? If we want add this restriction, then I would think that we should validate mainly to see if records have exact same values (may be concatenate all the strings and compare them). Ultimately, I think it all depends on your design.
Regarding your second question, I think this is definitely what you are going to assume and document. If we do not allow nulls for certain fields, then we should document it.
at 1. The question was more should i use the scheme like i described it. data two bytes for the valid record and so on.
About the duplicate entries ... i think since the URLyBird application is a broker for hotel rooms it would make sense that a hotel has more rooms, that have the same price and the same conditions. A Duplicate Key Exception would only make sense if want to create a record at a specific position and meanwhile someone else hat created it at this position.
at 2. This is not a question on validation its more a question on update logic, if a value is null i would permit it to update, meaning i only update the fields that have non null values. It's a bit like the search logic, where only criterias are taken that are not eqal to null.
This make a big difference for the caller of this method, should i give the update-method the whole data about the record or only the diffs.
But maybe im thinking to complicated. I will only update fields that are not equal to null.
posted 13 years ago
Well, regarding your #1, if you go the route of raising exception only when the create is called with a record number that already exists, there will never be a case because the signature of the method only takes String as input (I am assuming you are not forcing users to specify record number also as an element in this Array). I am not taking a functional scenario here like URLyBird in this case. I just gave an example of how to achieve uniqueness when no key is given to you. I think it is purely up to us to design and document as to whether we allow such a creation or not. As long as it is documented, I think either approach should be fine.
For #2, it is your choice again. How will you support a scenario where someone genuinely wants to nullify certain fields?
I guess I've been abducted by space aliens. So unprofessional. They tried to probe me with this tiny ad: