directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Chu <>
Subject Re: About entry cloning on the server...
Date Fri, 16 Aug 2013 16:40:41 GMT
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?

If an interceptor is going to make actual changes (add/remove) then you would 
have no choice but to clone.

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

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

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP

View raw message