Hello all,
I am trying to write an overlay that is able to get the previous/old values of an Entity, before it is updated by a modify/delete.
For that purpose, my first tries were to use a search from within the overlay, or pre-read.
I try many method, (inspired by existing overlay), but none seems to work for now: - use of pre-read seems to be very complicated; moreover, pre-read ctrl seems to be returned as already ber-encoded, meaning that I need to re-decode the ber to get the value ... this is (too) expensive - use of search from within overlay raise, for now, some problems: * if using translucent like call to 'be_entry_get_rw' I got deadlock on hdb * if using rc = nop->o_bd->be_search(nop,&nrs); from within overlay, it seems that response is sent also to remote client socket, and not stay confined to overlay call ( and, btw, I fail to get the result: rs->sr_un.sru_search.r_entry is NULL )
I, for sure, miss something. Do you have any clue, example, advice that may help me to continue ?
Thanks in advance for your help. hp tf
PS: This is a repost in the good mailing list, initial message post in openldap-devel@openldap.org, sorry for the inconvenience.
On 05/30/2011 09:56 AM, hptf wrote:
Hello all,
I am trying to write an overlay that is able to get the previous/old values of an Entity, before it is updated by a modify/delete.
For that purpose, my first tries were to use a search from within the overlay, or pre-read.
I try many method, (inspired by existing overlay), but none seems to work for now:
- use of pre-read seems to be very complicated; moreover, pre-read ctrl
seems to be returned as already ber-encoded, meaning that I need to re-decode the ber to get the value ... this is (too) expensive
This design is incorrect, since the pre-read you add to the request could interfere with an existing instance of the control issued by the client.
- use of search from within overlay raise, for now, some problems:
- if using translucent like call to 'be_entry_get_rw' I got deadlock on
hdb
- if using rc = nop->o_bd->be_search(nop,&nrs); from within overlay, it
seems that response is sent also to remote client socket, and not stay confined to overlay call ( and, btw, I fail to get the result: rs->sr_un.sru_search.r_entry is NULL )
You need to prevent response to take the default route by providing your sc_response callback in the slap_callback structure of the operation your overlay is modifying. This function needs to do whatever manipulation the logic of your overlay needs, including using sr_entry, and then return any logically valid response that is not SLAP_CB_CONTINUE (which triggers the default behavior, i.e. respond to the client).
There is plenty of examples in distributed overlays. See for example, slapo-pcache(5), slapo-memberof(5). If you failed to recognize this I wonder how you could code an overlay in the first place. Make sure you recognize how to get rid of resources attached to the SlapReply structure, which recently changed thanks to the many helpers implemented by Hallvard.
p.
openldap-technical@openldap.org