This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
I'm working on URLyBird 1.3.1 and trying to apply a design approach similar to that used in Denny's DVD project in the SJCD Exam with J2SE 5 book. The data files are similar except that the records in Denny's DVD project use UPC as the primary key and URLyBird has no explicit primary key but all of the required interface methods associated with records use record numbers as parameters or return values. In Denny's DVD project there is a recordNumbers Map containing the mapping beween a DVD's UPC and the record's file location, which is the resource used via read-write locks to control changes to the data file. I'm considering using the same approach where some simpler Collection object, such as a List, contain the file locations of each of the records and this Collection object controls changes to the file. I would use a Room value object which would have a record number attribute.
This approach seems natural; however, I'm concerned that binding the Room object too closely to the phyical location of the record in the file will make it more difficult to migrate to a real (non-file) database solution. Also, using this approach seems a little like overkill but I still need a way to lock the data file records while users are reading them and record number control seems central.
Can anyone see any real problems with the proposed approach? Anything I need to be aware of?
The data schema for ERLyBird db file doesn't contain a primary key so the only way to identify a record in the Database layer is via the record position.
I think it depends on your overall design, if you plan read and cache the records then you will need a list to store the records, however if you are just reading the records from the file each time, I don't think its necessary to store file locations of records as you can easily calculate the position if you store the offset of the first record i.e read the header and schema information and then store the file pointer.
Then because you now the length of each record you can seek to the corresponding record.
However you will still need a map for your locking manager.
I would recommend keeping the data layer generic, and just return the String array (Which could be compared to a ResultSet in JDBC).
Then you could create Data Transfer Objects in your business layer to return to your client.
RecNo is kind of treated as the primary key, however, a delete + create operation can mess up the primary key as it will be referring to a different record. Thus we need locking. [ March 27, 2006: Message edited by: Ed Tse ]