Re: (ITS#5773) bi_entry_get_rw() and overlays issue

[hyc@symas.com]

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:
> 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 
be_entry_get_rw().

> 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/