Re: (ITS#5328) backends sending/setting results

[h.b.furuseth@usit.uio.no]

Some fixed in HEAD.  Remaining bugs:

> Looking at the code, some overlays also send results when used as
> be_extended: pcache:pcache_op_privdb(), retcode, rwm, slapi_overlay.

Hmm - back-ldap does send_ldap_extended() too.  I don't know any of
that code well though.  Might have a look later, if nobody else does.


> * be->be_fetch() (bi->bi_entry_get_rw()):
>   The LDAP result code matters (...)  It can return just a boolean
>   in (...) back-relay.

I haven't looked at what it should return when not forwarding to the
backend.


relay_back_has_subordinates() is also broken.
It should return an LDAP result code, and if returning LDAP_SUCCESS it
must also set *hasSubs to LDAP_COMPARE_FALSE or LDAP_COMPARE_TRUE.  See
bdb_hasSubordinates() for an example.  However:


slapd's be_has_subordinates() API seems broken: It has no way to return
"don't know" or normal errors which slapd will pay attention to.  If it
returns non-success, test_ava_filter(,,,LDAP_FILTER_EQUALITY) returns
LDAP_OTHER.  Looks abit excessive.  OTOH test_presence_filter() assumes
that if the backend function exists then attr hasSubordinates does too.


>   back-ldap:ldap_back_entry_get() can return LDAP_NO_MEMORY.
>   Maybe that's OK and instead send_ldap_response() should change
>   negative negative result codes to LDAP_OTHER?

Awaiting opinions - will do the smallest change and patch back-ldap
if nobody says anything.

-- 
Hallvard