[DB-SIG] Q: database integrity, flush and corrupted files....

[Michael Scharf]

Hi Marc-Andre

M.-A. Lemburg wrote:
 > You do know about mxBeeBase, do you ?

Yes, but I forgot that it exists. I just tryed it and it seems
to solve my problem. (I was about to implement Extendible Hashing
but the BeeBase B+Tree is fast enough for my app).

I looked at BeeDict. The comments seem to indicate
that an index is not a reliable datastructure. My data
is actually an 16-byte string (md5 checksum) and an
integer. Would you recommend to store the data in a flat
file as well in case of a corrupted index?

With a simple stogare system like BeeStorage, after a failure it
seems possible to recover (without too much data loss).
Is there a recover procedure for an index?

I have another (little) problem. The BeeBase indes complains
about strings containing null. What is the best way to 'quote'
the null bytes?

What is the meaning of the keysize (what happens if keys are longer?)

What is the meaning of sectorsize? (I used 1024 (the maximum!?) insted
of 256 and the  data base of 2 million records gets smaller and is
constructed fater).

 > No; flushing has to be done explicitly using f.flush() for this.

Hmm, but if I write a gigabyte file on a 32Mb computer, the system
has to write out something at some point. Ok, it might be that this
is 'permanent' and the os writes it to the disk in a hidden mode,
but it becomes 'permanent' with flush. But what happens if there
is a power failure during the flush?

 > Flushing usually refers to writing line buffers out to the
 > disk. Whether the file system does write-through or not
 > depends on the settings of the file system. It also depends
 > on how you open the file, ie. buffered or not.

Ok, I test BeeBase a bit more and I might not be interested in
those questions anymore ;-)


Michael