Hi all!
I'm observing some unexpected (not surprising, though) behaviour with overlays.
I programmed a subgroup expansion overlay. It takes a DN in an attribute and copies one of its attributes to the containing entry (much in the same way as ExpandURL)
Now I'm trying to use that overlay together with dynlist:
Let dynlist expand an URL attribute into the entry and then let the new overlay explore the retrieved DNs.
My idea is to let the callback do the work: just chain both overlays...
The resutls are not as expected: no matter the order a use in the overlay stack, my overlay won't see the values retrieved by dynlist.
I think it has to do with the way the attribute values are retrieved. I have tried backend_attribute(...) an fe_acl_attribute(...) in my code but both seem to skip the overlay chain. I guess they take the attribute values from the backend thus ignoring the ones retrieved "artificially" by dynlist...
So the question is: is there an easy way of searching the attribute values from an Entry itself instead of against the backend? Does anyone remember any example in the official code where I can look?
And, by the way, what does the final _ex in some function names mean?
Thanks for your attention!
José Marco wrote:
I'm observing some unexpected (not surprising, though) behaviour with overlays.
I programmed a subgroup expansion overlay. It takes a DN in an attribute and copies one of its attributes to the containing entry (much in the same way as ExpandURL)
Now I'm trying to use that overlay together with dynlist:
Let dynlist expand an URL attribute into the entry and then let the new overlay explore the retrieved DNs.
My idea is to let the callback do the work: just chain both overlays...
The resutls are not as expected: no matter the order a use in the overlay stack, my overlay won't see the values retrieved by dynlist.
I think it has to do with the way the attribute values are retrieved. I have tried backend_attribute(...) an fe_acl_attribute(...) in my code but both seem to skip the overlay chain. I guess they take the attribute values from the backend thus ignoring the ones retrieved "artificially" by dynlist...
Well, if you want to act on data as returned by dynlist, you need to get it from the data flow from that overlay back to the client. That is, you need to implement on_response() so that it takes data from the rs_entry field in the SlapReply structure that is populated by the preceding database/overlays functions. Also, note that you're not supposed to muck (i.e. write) to entries as passed by this call, as they could be read-only. You can safely do it if the entry's flags contain REP_ENTRY_MODIFIABLE; otherwise, you need to copy the entry, and optionally mark it as such. Also, if you do not plan to free the entry's copy yourself, you'll need to mark it as REP_ENTRY_MUSTBEFREED.
So the question is: is there an easy way of searching the attribute values from an Entry itself instead of against the backend? Does anyone remember any example in the official code where I can look?
attr_find(); it's used everywhere in the code.
And, by the way, what does the final _ex in some function names mean?
you mean _X()? Usually, it refers to functions that take an optional context for memory allocation (if not NULL).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-software@openldap.org