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