This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi, guys. I was wondering if anyone knows of a good, efficient way to handle deleted records. It's the only thing I honestly cannot come up with a good solution for. It breaks the uncoupling of my code completely, because to reuse deleted records, I would have to make details of my io code available to higher-level code, instead of keeping the details hidden.
Does anyone have any advice?
Anton Golovin (email@example.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
I think you had a similar backend strategy to myself.
My Data class is the highest level of my .db package, I think that is what everyone has.
Below that the data handling classes implement a DataAccess interface. This interface specifies an isDeleted(int recNo) method. But Data never needs to call it.
Both classes that implement that interface implement that method in different ways, DataCache asks a Set that tracks deleted records if it contains the requested record. DataFile (RAFwrapper) seeks to the requested row and reads the flag.
The highest use of this method is within DataCache when it builds the cache of deleted records.
My Data class, does little more than proxy for DataCache, apart from the addition of find and locking functionality.
SCJP 1.4, SCJD
Joined: Jul 02, 2004
I got some major re-thinking going about the schematics. I am implementing a DBRecord class for every record, to be kept in a DBCache. Before, I just could not figure out how to handle record numbers in the context where some records are deleted. So my schematic now looks the following:
Data (the data-access class) contains > DBCache (the cached data) >> contains DBRecord > DBRecordManager (the record manipulating class) contains >> DBSchema (the data-file schema) >> DBIOManager (the IO class) makes >> DBRecord (the logical representation of a record) > DBLockManager (the lock-manager class)
and exceptions, etc...
I also have a DBUtilities class to take care of conversions, etc. I am not implementing a DataAccess interface, although it is a great idea to "synchronize" different ways of getting at data.
I am sure of everything except the memory requirements of DBRecord.
Perhaps it's doing more than necessary... [ August 16, 2004: Message edited by: Anton Golovin ]