Le 8/16/13 6:40 PM, Howard Chu a écrit : > 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?
This was, in the previous stages of the server, a guarantee that the cached entry was not modified in any way. Again, corectness was favored over performance... > > If an interceptor is going to make actual changes (add/remove) then > you would have no choice but to clone. We did it the other way out : first clone, then let interceptors do whatever they want. We where supposed to let anyone write an interceptor, and we wanted to protect the server against a wrongly written interceptor. This is, in retrospect, too expensive. > >> 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. Makes sense, and may save a lot of CPU cycles... Time to experiment now ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
