Søren Holm sgh@sgh.dk schrieb am 08.09.2022 um 20:23 in Nachricht
f094cb45-3c00-785c-ed4d-3c7e78e2cf91@sgh.dk:
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.
Also I think the size of SQlite database as use in Firefox would qualify as "toy database" (a few MB at most, if at all). So I'm surprised that Firefox switches the "database". Real databases have diffetent requirements when extended downtimes are not always an option. Firefox is not a good example here IMHO.
Regards, Ulrich
-- Søren Holm