Hey folks,
In the search callback, I need to check whether an entry exists, and if not, create it based on an another entry used as template (duplicating also eventual tree elements below it, if they exist).
For example, if cn=a,cn=TESTVAL1,ou=group,dc,dc doesn't exist, it should be created from cn=a,cn=TEMPLATE,ou=group,dc,dc.
The created entry (and the eventual subtree) should not persist and should be dropped after the operation finishes.
Questions:
1) What's an elegant way to duplicate an entry in this way where an exact copy should be made, just with a different DN?
2) Since the entry creation is done in search callback, it can't be just "slipped in" like it would be possible in response callback alone, so how do I mark the created entry for removal when the operation is done?
Can this be scheduled automatically with entry flags (like REP_ENTRY_MUSTBEFREED), or there would have to be a manual mechanism for deleting entries in response callback?
Thanks, -doc
On Fri, 11 Apr 2008 23:53:04 +0200 Davor Ocelic docelic@spinlocksolutions.com wrote:
Hey folks,
In the search callback, I need to check whether an entry exists, and if not, create it based on an another entry used as template.
Ok, got it. The last issue is:
When I've got the new entry created inside op_search handler, how do I make it "persist" and end up returned to the client?
I've tried setting rs->sr_entry to the new entry and setting rs->sr_err to LDAP_SUCCESS, but the entry is lost somewhere along the way and it's not seen at overlay's exit.
-doc
Davor Ocelic wrote:
On Fri, 11 Apr 2008 23:53:04 +0200 Davor Ocelicdocelic@spinlocksolutions.com wrote:
Hey folks,
In the search callback, I need to check whether an entry exists, and if not, create it based on an another entry used as template.
Ok, got it. The last issue is:
When I've got the new entry created inside op_search handler, how do I make it "persist" and end up returned to the client?
I've tried setting rs->sr_entry to the new entry and setting rs->sr_err to LDAP_SUCCESS, but the entry is lost somewhere along the way and it's not seen at overlay's exit.
The op_search handler can inspect and alter the request parameters, and do various things based on those parameters. But to return a temporary entry that won't be seen by the underlying backend, you have to call send_search_entry yourself.