Re: Overlays : Cache - Entry - AttributeDescription

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Johan Jakus writes:
> 1.      In my overlay, I search for the attribute of a parent (recursively)
>  and then, I return it in the response using the ?attr_merge? function as
> used in the ?content? overlay. But, this seems to be a permanent change, the
> server will always return that attribute, till I restart the server. It?s
> like if the ?attr_merge? function add the attribute in some kind of cache
> that is only cleared when the server shuts down. I ?would like my attribute
> to be return only when I ask it, is there some other function that allow
> this or maybe a way to clear that cache?

Yes, the backend/overlay which returns an entry often owns that entry.
If you are result and modifying rs->sr_entry, rs->sr_flags describe
ownership of the entry and if it is modifiable.  You can call

	rs_entry2modifiable( op, rs, on /*the overlay*/ );

to ensure rs->sr_entry is modifiable.  If necessary, this duplicates
the entry and frees/releases the old one.  This invalidates any pointers
to/into the old sr_entry.  Note how e.g. overlays/valsort.c re-reads
rs->sr_entry->e_attrs if the entry was replaced.

At other times you may prefer to duplicate an entry "by hand"
with entry_dup() to get a modifiable copy, and free it later with
entry_free() or by setting the MUSTBEFREED flag in rs->sr_flags.

If your overlay needs to free the entry in a special way, it can
set a entry release function and set the MUSTRELEASE flag to alert
other code that the entry can't just be entry_free()d.

> 2.      I need to free some variables at the end of the request. It seems
> that the server goes through the response function one last time at the end
> of the request with an empty entry, I used  that condition to free my
> variable. This seems to work perfectly, but is there may be another way to
> do that?

The on_response function is a convenience feature making use of
op->o_callback.  You could use that directly instead.  In that case,
use callback.sc_response for your response and callback.sc_cleanup for
cleanup.  The cleanup function should not assume that the sc_response
has been called, since Abandon and a few other things don't.

> 3.      To determine what attribute I need to look up for parent?s
> attributes, I use a symbol before the attribute in the search request (ex:
> ?_street?). This means that when the attribute arrives in the search
> function, it has no attribute description because the attribute name isn?t
> valid of course!

I'm not sure, but this sounds like a hack which some future OpenLDAP
version might break with stricter schema schecking or something.

> So, I change the name, save the attribute name for later
> use and then use the ?slap_str2ad? function do add the attribute
> description! But this means that the server as to go look for that attribute
> description again and this means decreasing the performance. My question is:
> Is there a way to change and saved the attribute name before the server
> loads the attribute descriptions and calls the search function?

Not sure, but possibly you want <struct Operation>.o_extra.  Each
backend and overlay may register info there on the way into an
operation, and remove it on the way out.  See e.g. overlays/memberof.c.

However, have you checked optimizing away this extra work saves enough
time to be noticeable?  Possibly the best solution is to not optimize it.

-- 
Hallvard