simplicity vs safety with complexity

[Matthias Andree]

"Tom Anderson" <tanderso at oac-design.com> writes:

> Right, but we have recovery procedures for the non-transactional version 
> too.  Therefore, the transactional version should be capable of being 100% 
> as simple as the non-transactional version.  The recovery will simply be 
> more effective and reliable.  It seems like the reason why it is complicated 
> is because of BerkeleyDB, but then again, I don't actually know how 
> complicated it is since I haven't attempted to use it yet.

It is much too complicated. About every Berkeley DB subsystem needs to
be taken by the hand and guided through the world. It is very flexible
but also very cumbersome. As we have seen over the past few versions,
SleepyCat are working towards making Berkeley DB easier to use for both
programmers and users, although the former group (that means me
currently) will only profit in the distant future.

> If backing up or copying wordlist.db is simply changed to backing up
> or copying the whole directory rather than just a file, that doesn't
> seem like such a big deal.  Nonetheless, would it be possible to store
> the transaction logs inside of wordlist.db???

Not with Berkeley DB up to 4.3. It is possible to let bogofilter purge
logs on a regular basis with little effort. Given that there's bf_tar
and you only need to stuff the output into a file, backing up is a
non-issue except for the distributors' madness of renaming and moving
around the db-util files.

Even sqlite writes a separate file while it has pending transactions.
SQlite appears to be an awful performer under lock congestion though,
t.lock3 can take ages on real hard disks, but otherwise it is easy to
use. It is considerably slower than Berkeley DB. Likely a tribute to the
much more complex indexing and command set that SQL entails.

-- 
Matthias Andree