Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of mail@stefan-seelmann.de
 designates 109.239.48.183 as permitted sender)
Message-ID: <520E523D.408@stefan-seelmann.de>
Date: Fri, 16 Aug 2013 18:24:29 +0200
From: Stefan Seelmann <mail@stefan-seelmann.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130806 Thunderbird/17.0.8
MIME-Version: 1.0
To: dev@directory.apache.org
Subject: Re: About entry cloning on the server...
References: <520E502E.4060308@gmail.com>
In-Reply-To: <520E502E.4060308@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Sounds reasonable, lazy cloning, give it a try.

Kind Regards,
Stefan


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