[Date Prev][Date Next]
Re: Overlays : Cache - Entry - AttributeDescription
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.