we have a DBVERSION file in the top database directory
Its content is:
bdb/5.3/libback-ldbm/newidl/rdn-format-3/dn-4514-1
and tracks libdb version , variant of idl list, entryrdn vs entrydn and dn-rfc.
There are also the same DBVERSION files in each instance database directory, but all the settings are global, so all instances have to use the same config and libdb. Only when it was possible to restore a single backend from a backup there might have been differences, but this is no longer possible.
Also the read of DBVERSION checks for a dataversion, which is never set, and the handlin of the idl-switch is someho obscure, it needs anothe param to be set to allow a change - and I am notsure it is realy working well to switch from new to old or vice versa.
So I propose to cleanup this and have only ONE version file and verify that it processes the settings correctly
Seems reasonable to me. The main concern I have is if we had a future case of:
db/userRoot/id2entry.db4 db/otherRoot/id2entry.lmdb
So I guess this depends how your future backend work will look about support multiple db types concurrently (or not).
Metadata Update from @firstyear: - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None
@firstyear IMHO the new backend isolation should be able to handle several backends with different database layer but I would prefer to go that way. Having an instance running with a single database layer (environment + db files) at a time would simplify tests and support work. It looks to me acceptable to have a full import when moving to a new major release with a new default db layer.
It is not only a question of simplifying test and support, we do have transactions spanning multiple backends, we have csn and changelog commit management across multiple backends - I do not see how this should work if the backends use different database implementations.
And I do not see the benefit and need.
I agree - I don't think we should have different backend storage mechanisms, as it adds pointless complexity.
So provided that "all backends" must use the same lower-level db type, then having a single DBVERSION is acceptable to me.
Here is one more thought on the idl switch. As far as I am aware the old-idl is not used and I am not sure how well it really still would work.
I was hesitant to remove the idl switch because there are suggestions for a new idl format (see #49416) which I think are promising (even if we do not implement them in rust). But looking up the discussion with @firstyear and @tbordaz (unfortunately internal by mail) we had almost agreed on encoding the index type in the index itself by a special key, thus allowing to handle indexes different according to what would be optimal.
With that in mind we could give up old-idl, if introducing a new idl format handle this transparent in the index itself.
Metadata Update from @mreynolds: - Issue set to the milestone: 1.4.2
Metadata Update from @mreynolds: - Issue priority set to: normal - Issue set to the milestone: 1.4.4 (was: 1.4.2)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/3631
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.