[Date Prev][Date Next]
Re: (ITS#5328) backends sending/setting results
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
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.