On Thu, 5 Apr 2001, B. W. Fitzpatrick wrote:
> Everyone has talked about performance, efficiency and readability
> issues that going to a human-readable format would solve, but no one
> has mentioned anything about how they will handle atomic transactions
> in this case.
>
> Just a little reminder.
Good point! That could be a bit of a showstopper, couldn't it?
In principle, there's no reason you couldn't implement atomic transactions
on top of a text-based format (perhaps with binary data on the side), but
it's certainly much easier to just use Berkeley DB and let it handle it all
for you. (This might be a good reason to use Berkeley DB and export to the
readable text files, as I suggested earlier.)
Of course, since Berkeley DB exposes API functions for its transaction
system that can be used without using its access methods, it would be
possible to use those API's to help manage a text-based format. Possible,
but not easy -- code would have to be written to replay and/or rollback
operations, as well as manage the relevant information for the journal.
Berkeley DB's lock manager could probably be utilized. And, of course, all
this new code would need debugging. It would be no small undertaking...
It would take a lot of work to implement proper transaction semantics with
a text-based format; is it worth all that trouble, or should the native
format remain binary after all? (In that case, I'd still advocate allowing
exports of the binary data to a text-based format for inspection as well
as for portability and interchange.)
Deven
Received on Sat Oct 21 14:36:28 2006