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

["Pierangelo Masarati" <ando@sys-net.it>]

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

We may want to extend the rewrite engine to use
bervals first, and then using patterns other than
regex, since in most cases only the naming context
or part of the DN must be changed; thinking of
something like

"(.*)<old nc>" "%1<new nc>"

could be implemented by normalizing <old nc> and
<new nc> and by directly comparing the end of the
value, or so, e.g.

"{subtree}<old nc>" "<new nc>"

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

Agree.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it