>>> Søren Holm <[email protected]> schrieb am 08.09.2022 um 20:23 in Nachricht <[email protected]>:
> 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. 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
