directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: About entry cloning on the server...
Date Fri, 16 Aug 2013 22:56:47 GMT
Le 8/16/13 6:40 PM, Howard Chu a écrit :
> Emmanuel Lécharny wrote:
>> Hi guys,
>> this morning, while I was trying not to wake up, I had an idea that
>> could change a lot.
>> Whenw e do a search, we get back an entry from the backend. As we may
>> change this entry befoe sendng it to the user, we do a deep copy of it.
>> The rationnal is that the user may require only a few attributes, or the
>> authorization layer might hide some of the attributes (or even some of
>> the values), or some interceptor might remove or add some attributes
>> and/or values (like the collectiveAttributes interceptor).
> This doesn't make much sense to me. If authorization or something
> wants to hide attributes, they should be filtered out during the
> output stage, why do you need to clone anything?

This was, in the previous stages of the server, a guarantee that the
cached entry was not modified in any way. Again, corectness was favored
over performance...
> If an interceptor is going to make actual changes (add/remove) then
> you would have no choice but to clone.

We did it the other way out : first clone, then let interceptors do
whatever they want. We where supposed to let anyone write an
interceptor, and we wanted to protect the server against a wrongly
written interceptor. This is, in retrospect, too expensive.

>> Ok, by cloning the whole entry, we guarantee that we can cache it for
>> any further requests, so this is mandatory if we want to deliver some
>> decent performances without hitting the disk for each entry we have to
>> return.
>> Now, if we consider that most of the time, the attributes will not be
>> changed (ie, it's quite rare that we hide or add a value of an
>> attribute), so it would make sense not to clone the attributes.
>> I was thinking that if we just do a shallow clone of the entry, we
>> should save a hell lot of processing and time...
>> Would it fly ? It depends. There are cases where we want to do a deep
>> copy of the attributes too :
>> - when we have to hide an attribute
>> - when we have to replace the attribute's name by the one provided by
>> the user (if the user request for an entry with OBJECTCLASS, then the
>> attribute's name should be OBJECTCLASS, nothing else)
> This is probably a bad idea. e.g. OpenLDAP always returns attributes
> using their canonical name. The old "liberal in what you accept,
> strict in what you produce" policy applies here.

Makes sense, and may save a lot of CPU cycles...

Time to experiment now !

Emmanuel Lécharny 

View raw message