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 hyc@symas.com schrieb am 08.09.2022 um 01:34 in Nachricht
4bc80e7e-17f9-b385-6b11-2aab806edc43@symas.com:
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