ldb for 3.0.24?

[Stefan (metze) Metzmacher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tridge at samba.org schrieb:
> 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.

ok, then I think we should have such a version per attribute syntax
and store this version in the database, and trigger a reindex if the
versions mismatch.

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

yes, but only in some cases, which happen once in month,

>  > 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!

that's a different problem, that we can track via the per attribute
syntax version.

but for me it makes no sense to limit the attribute_name ->
attribute_syntax mapping to what active directory needs.

I'll descripe that a bit more in my next mail.

>  > (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?

by load I mean what ldb_register_samba_handlers() do

you first intoduced the attribute handlers just for display
attribute values nicely in ldbsearch and ldbedit

and what I mean is that we need to keep the static mapping of
names to syntax in the ldap/ildap backends, as they don't have
@ATTRIBUTES, at INDEXLIST... objects.

Because it's really nice to use ldbedit against windows and see
objectGUID and objectSID as strings...

metze
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFFbrQfm70gjA5TCD8RAk8hAJ4kGH79Bzjlh8KAzkJ5cvhFnbO7fgCgtpyE
LO68kf11wap1Vemis1Q88tI=
=fiTE
-----END PGP SIGNATURE-----