ando@sys-net.it wrote:
h.b.furuseth@usit.uio.no wrote:
ando@sys-net.it writes:
I think bi_entry_get_rw() needs work.
Or maybe phase it out in favor of some other call?
In fact, as also discussed in ITS#5628, callers either return the entry or have no means to modify the arguments of the request.
It has more troubles than that. See e.g. the notes about passing rw=1 (write) to it here: http://www.openldap.org/lists/openldap-devel/200803/msg00055.html And there is no equivalent of the REP_ENTRY_MUSTRELEASE flag which says to pass an rw=1 argument to bi_entry_release_rw().
Well, I see many places where an entry needs to be fetched. Typically, it needs to be done read-only.
In fact, the rw flag makes no sense. You can only fetch an entry ro; if you actually fetched it for write access and modified the entry, there's no API to commit the changed entry to stable storage. You would only be making a transient change to a cached copy (which could disappear as soon as you release the entry). So if we're going to change this API, the first thing to do is get rid of the rw flag. You must use be_modify if you want to change anything about an entry...
So the difference between bi_entry_get_ro() and an internal search is that if we are fine with the entry in-cache, we save lots of manipulation. However this might no longer suffice when overlays muck with the entry (like slapo-rwm). Moreover, when overlays are present, I see the need to:
- run it like it came from outside, going thru all the overlays
That's what overlays currently do when they do the bd_info swap and then call be_entry_get_rw().
- go straight to the underlying database
That's done by calling bd_info->bi_entry_get_rw()...
- go thru overlays starting at some point (e.g. when called from inside
an overlay under the assumption the entry is fetched as that overlay would see it, so with only any possible mucking from overlays layered deeper than the caller).
That's what overlay_entry_get_ov() does. Also note that passing a NULL overinst here accomplishes (2).
This probably needs to modify the way callbacks are actually called, allowing some "after self" feature in playing not just the overlay list, but also the response (and the cleanup).
Then we need an "opcode" for this, so that response / cleanup handlers know why they're being invoked.