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. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
