Den 08.09.2022 kl. 18.20 skrev Howard Chu:
Søren Holm wrote:
Den 08.09.2022 kl. 17.30 skrev Howard Chu:
Ulrich Windl wrote:
Howard Chu <[email protected]> schrieb am 08.09.2022 um 01:34 in Nachricht
<[email protected]>:
Steffen Michels wrote:
Hi,
We are considering using the mdb.master3 branch of LMDB, but it is not clear
to me whether the data.mdb format will remain stable. Is there a chance that
another migration of all databases will be required in the future when
switching now?
Yes. It is still unreleased because additional changes to the freelist
format are planned,
and possibly a few other changes.
In any case, mdb_dump/mdb_load will always work for migrating to a new
version.
I think at some point an inplace upgrade would be the way to go.
On Linux filesystems, you could even upgrade yout ext3 to btrfs ;-)
That will never happen here. Supporting an in-place upgrade requires the
library to support
old and new formats simultaneously, which is a waste of RAM. Anything that
pushes the object
code size of the hot path over 64KB is a non-starter.
Well - if the old version is kept in it's own memory region the new version
will still fit within it's own 64KB region.
If the library should not contain both how would you image an application
managing the upgrade by itself. I mean, the symbols are names the same etc. so
it is
difficult to link with both the old and new version.
A database upgrade is an administrative change, thus handled by the
administrative tools mdb_dump/mdb_load.
There's no need to handle it in an application's main runtime code.
Are you sure about that? Let's say that fx. Firefox of SQlite (v4 will
be on top of LMDB afaik) starts using LMDB for internal storage. Asking
the user to run the administrative tools is a bit much. A software
controlled migration path is crucial.
--
Søren Holm
