New version, database incompatible -retrain again!

[Matthias Andree]

Am 13.02.25 um 14:26 schrieb Adrian via bogofilter:
>> That should work, at least assuming same endianness and word widths (32
>> vs. 64 bits). There is some support in bogofilter to look at endianness
>> properly, but that's been a while.
>>
>> We've made the unfortunate decision or omission at the time that the
>> sqlite3 database also uses the ".db" suffix as the Berkeley DB stuff does.
>> Berkeley DB itself should have been able to upgrade if the database was
>> closed properly such that it would not need recovery, or were an intact
>> non-transactional database.
>>
>> OTOH since Oracle bought them, my interest in Berkeley DB has pretty
>> much vanished. Patches disappearing from the website, licensing changes
>> with DB 6, and more that annoys me,
>> so I think we should switch the default and mark it deprecated, and
>> maybe keep them readable so distros can build Berkeley DB based bogoutil
>> versions additionally and ship them so that users can migrate away.
> Thanks for the info Matthias.  Endianness and word widths match, but
> both versions were on the same hardware so maybe that's to be expected.
> But does that affect the text dump?  So long as my bogofilter install
> matches the DB I'm dumping the output will surely work in bogoutil -l
> on another install and DB?

The bogoutil dump text output is system agnostic and independent of the
database driver. That one should be transferable to other computer
systems no matter what.

> The dump and reload is a useful low-level way to migrate or manually
> tweak the database.
>
> If Sqlite is fast enough, it's a more familiar DB to me and one I have
> support apps for, so I'd always choose it.

In a benchmark I did ages ago, it used to be half as fast as BerkeleyDB
at the time, but we didn't then have LMDB, and maybe not KyotoCabinet
either.

Some benchmark on a SSD would be interesting...