directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject About entry cloning on the server...
Date Fri, 16 Aug 2013 16:15:42 GMT
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...

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com 


Mime
View raw message