On 15 May 2000 22:10:21 CDT, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]> said:
> However, after poking around in the db docs (from now on, when I say
> db here, I mean the sleepycat db), I'm wondering if this might be much
> better candidate for that job than "rolling our own" fs subtree
> approach. For now, I'm putting aside the question of whether or not
> we might want to break out the current engine data as db tables. For
> now I'm just interested in considering if using db might be the best
> way to give us the "sectional data store".
Lots of "food for thought."
> Things to think about:
>
> - db supports a "subname" argument in the "open" call, so you can
> have multiple db tables inside one file. With even marginally
> careful subnaming, we can use the db for all our "sectional
> subfiles" right now, and still be able to break out the engine
> data into tables later if we decide it's a good idea.
Surely sounds good.
> - db appears to have industrial strength locking, transactions, and
> logging with full recoverability if requested.
The recent comments suggesting replacement of the PostgreSQL underlying
storage engine with this implies that this provides an _appallingly_
potent engine to this purpose.
> - db has dump and load to/from text format file routines, so people
> interested in a accessing their data in a text format will have a
> well documented method.
This will be a very popular aspect to it.
> - db supports hot backups using normal unix tools. You can just
> tar/cp/whatever your file while its open with no ill effects as
> long as the app properly uses the built in transaction mechanism.
I hadn't been aware of this; a Rather Attractive Feature for would-be
High Availability apps...
> Also, though this probably belongs as a separate discussion, and I
> haven't thought heavily about it yet, what about actually using it as
> our engine data storage format (i.e. splits as a subtable,
> transactions as a subtable, accounts as a subtable, etc.)? It's not
> as sophisticated as SQL (though that's possibly a plus as much as a
> minus) since it's only a one dimensional hash, but you can build
> anything you want on top of that, and, as compared to our current
> approach, it seems like it might be better across the board.
> Of course, this question is orthogonal to whether or not it's the
> right thing to use to implement the "sectional data store" for
> non-engine data.
I rather like it as an approach.
> The nice thing is that if we do decide for now to just use it for our
> non-engine data (where the engine data is just a binary "blob" stored
> as one of the subnames in the database file), it should be a very
> straightforward step to break out the engine data into sub-tables
> later if that turns out to be a good idea.
>
> Thoughts?
>
> (Bracing for a long thread...)
I _rather_ like the idea of being able to use db_dump, which, I would
point out, comes as a standard part of the libdb2 distribution, to
serialize the DB out in text form.
The fact that it provides reasonably full transactional support is a
goodly bonus.
--
Out of my mind. Back in five minutes.
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
