directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: About entry cloning on the server...
Date Fri, 16 Aug 2013 16:24:29 GMT
Sounds reasonable, lazy cloning, give it a try.

Kind Regards,

On 08/16/2013 06:15 PM, 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).
> 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)
> But even then, we can easily clone the associated attributes on the fly,
> and replace the existing one in the cloned entry...
> I think that worths an experiment...

View raw message