[Date Prev][Date Next]
Re: (ITS#5773) bi_entry_get_rw() and overlays issue
> email@example.com wrote:
>> firstname.lastname@example.org 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:
>> 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:
> 1) 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
> 2) go straight to the underlying database
That's done by calling bd_info->bi_entry_get_rw()...
> 3) 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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/