ldb for 3.0.24?

[tridge at samba.org]

Metze,

 > I think using a application version string for triggering a index
 > regeneration is a very bad idea, because you would not be able to run
 > samba3 and use samba4's ldbedit.

ok, then I'd like to propose a different alternative. We can have a
LDB_INDEX_VERSION define in ldb.h. This can be stored by ldb and
checked at connect - if its not what is stored an index regenerate is
triggered.

Maybe we won't need it for the current issue being dealt with about
memberOf (I think there is a good chance we can avoid that without
resorting to such mechanisms), but someday we are sure to run across a
case where we do need to change a canonicalisation function, and will
need a way to trigger a reindex.

I know that such a forced reindex is not without its problems (the
most obvious being the problem of two ldb libs of different versions
being attached at the same time), but I still think the mechanism
could prove to be extremely useful in some cases.

 > I think the way to handle this is to make sure the attribute handler of
 > an attribute can only be changed by changing the @ATTRIBUTES object,
 > and this change will force the index regeneration.

To be LDAP and AD compliant, some of our canonicalisation handlers
(which are used as the basis for indexing) must have very specific
forms. If when we write those ones we never put any bugs in then
everything is of course OK, but I think that relying on us never
having a bug is a bit tricky!

 > (for the ldap backends, we should still load the hardcoded attribute
 > handlers, for the ldif handling)

I'm not sure what you mean by "load" in this case?

Cheers, Tridge