cleanup and improve the use of the DBVERSION file(s)

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/50575

• Created at 2019-08-29 17:34:39 by lkrispen (@elkris)
• Assigned to nobody

---

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

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-08-30 00:49:34

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).

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-08-30 00:49:35

Metadata Update from @Firstyear:

• Custom field origin adjusted to None
• Custom field reviewstatus adjusted to None

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2019-09-02 11:17:23

@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.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2019-09-02 15:19:28

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.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2019-09-03 01:19:29

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.

[389-ds-bot]

Comment from lkrispen (@elkris) at 2019-09-04 10:55:55

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.

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2019-09-05 17:56:11

Metadata Update from @mreynolds389:

• Issue set to the milestone: 1.4.2

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2020-03-04 16:35:11

Metadata Update from @mreynolds389:

• Issue priority set to: normal
• Issue set to the milestone: 1.4.4 (was: 1.4.2)