RE: back-meta does not compile (ITS#2483)

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of ando@sys-net.it

> As far as I can tell, the LDAP_CACHING code suffers
> from an unnecessary overimplementation, since I don't
> see the need to split caches on different local
> databases.  I think caching should have been kept
> as separate as possible from the actual storage,
> using callbacks to invoke the more appropriate
> storage.  In fact, now caching relies on back-ldbm,
> while an upgrade to back-bdb would be better, since
> we might decide to get rid of back-ldbm at some point.

Yes, I still have some issues with the current code. As I noted in a previous
post,  the flag indicating "this is a cache" should be an attribute of the
actual database, not a flag in the Operation. If the cache code's sparse DIT
usage were changed slightly, we wouldn't even need special treatment in the
backend.

> We may also decide to get rid of back-meta itself,
> to glue together multiple instances of back-ldap.

I expect to have a framework for configuring stacked modules checked in Real
Soon Now. I haven't done a full audit yet of what other features in back-meta
need to be migrated into a new module if we get rid of back-meta. So far all
I know is we want the rewrite engine to be usable with other backends, and we
need a mechanism to allow multithreaded, asynchronous searching of
subordinate backends.

The latter can be done with not much work, simply submitting new Operations
into the thread pool for each subordinate search. We can add an optional
argument to the "subordinate" keyword, e.g. "async" to tell back-glue to
search a particular backend asynchronously.

> I think we should move the caching code, which is
> itself a nice piece of software, into a separate layer,
> and make it call arbitrary storages at well defined
> entry points.

Yes...
Currently the code uses a special flag that allows it to perform some
privileged operations, such as creating entries whose parent does not exist,
creating sparse entries without schema checking, bypassing search limits, and
bypassing access controls on its operations. Rolling all of these features
into a single flag is unnecessary in some areas and just inflexible
otherwise.

For the latter two conditions, all that's needed is to set the operation's DN
to the backend's rootDN when calling the backend.

For bypassing the schema checking, we should have simply added a new backend
flag SLAP_BFLAG_NO_SCHEMACHECKING; there may be other situations where we'll
want this functionality and it shouldn't be specifically tied into this cache
code.

For the sparse DIT, the current approach requires that each database backend
be modified to allow this usage. It would probably be better if the cache
simply created stub entries for the missing parents, then it would be usable
with any of the database backends without further modification.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support