I have a problem with database implementation. As my DBAccess interface describes it should be done quite flexible. I have following method:
// Modifies the fields of a record. The new value for field n // appears in data[n]. Throws SecurityException // if the record is locked with a cookie other than lockCookie. public void updateRecord(long recNo, String data, long lockCookie) throws RecordNotFoundException, SecurityException;
which - I guess - should allow to update whole record not only the last field where booking value (custormer id) is stored.
Here I fall into a problem. - client A reads record 1 (info about hotel room in Paris) - client B updates record 1 (now room is in London) - client A updates record 1 (room booking)
Of course from my GUI reqirements this example does not make any sense. Nobody whants me to change room location.
I just wish to implement databse layer in a flexible way. Does it require to keep versions of all records on a server and client side and match them while updating? Where can I put that version number when provided database interface does not include this information?
I have the other assignment, Bodgitt and Scarper, but they are analoguous I guess. B&S is about booking contractors, not hotel rooms, but that does not matter. The assignment requires only that the user should be able to book a contractor, i.e. assign it a customer id. The location of the contractor will not change. I have assumed that changes to the contractor name, city etc will be done with another application, presumably not one of which there are multiple concurrent clients. This is why I'm not planning to deal with this issue. I am still working on my assignment and I don't know how it will be evaluated, but my plan is to allow updates of city etc in the server, but not implement them in the client.
It is nice to see somebody giving me a "ranch hand"
I understand you will take cake about checking if a record is booked on the client side and your server provides function similar to:
It looks like your server provides full access to your database. Teoretically any program (even not your client) can access your database and change data via such an interface.
For sure it is flexible but from the other hand makes data your client changes/books unreliable and this is why I created this topic on the forum.
Wouldn't be better to provide on the server:
instead of update(...)??
Positives: - only server would know what booking means (for URLyBird it would be updating 7th field in record) - record cannot change (except booking/deleting) and for sure client books what he sees on the screen. - any program would be able to use this server without creating a mess in database
Probably everything will be ok if described well in "General Considerations".
I have the same problem but I choose to isolate it on my back end(rod) layer. Here I have a RecordChanger which encapsulate the "record changing algorithm" for URLyBird - set or reset the 7'th field. In this way is easy to change the "booking algorithm" in the future.
I can atach my RecordChanger interface if you want it.
SCJP, SCJD, SCWCD, OCPJBCD
Joined: Jun 21, 2006
I chosed the same solution. Server offers: book(Room r, String customer) This requires me to repack String to Room on the server side as well. It simplifies also implementation of the client.
Maybe instead of interface for your RecordChanger you can tell me how do you handle metadata problem.
Where do you store information that owner is 7th field in record or hotelName is 1st etc.? This is my current problem.