[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

I missed the posting on the bugs mailing list. I agree with most of your

Once I ensure that the current implementation compiles and works properly,
I will discuss the issues below on the developer mailing list before
changing the implementation.

----- Forwarded by Apurva Kumar/India/IBM on 05/15/03 10:45 AM -----
                      "Howard Chu"                                                                                                          
                      <hyc@highlandsun.com>         To:       <openldap-devel@OpenLDAP.org>                                                 
                      Sent by:                      cc:                                                                                     
                      owner-openldap-devel@O        Subject:  RE: back-meta does not compile (ITS#2483)                                     
                      05/14/03 06:17 PM                                                                                                     

> -----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
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
usage were changed slightly, we wouldn't even need special treatment in the

> 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
Soon Now. I haven't done a full audit yet of what other features in
need to be migrated into a new module if we get rid of back-meta. So far
I know is we want the rewrite engine to be usable with other backends, and
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.

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

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

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

For the sparse DIT, the current approach requires that each database
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
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