vargok(a)yahoo.com wrote:
Full_Name: K Vargo
Version: 2.3.32
OS: Linux (RH-EL4)
URL:
ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (128.237.233.195)
Given a Base-DN, Subtree scoped ldapsearch, while the database contains
non-DN-matching items runs up against the 'assert(0)' in Back-SQL/search.c
+2186.
Based on how the selection works, there doesn't appear to be a reason for the
assertion. The FIXME does not indicate WHY the dnIsSuffix should never fail:
the comparison in dnIsSuffix tries to compare incompatible-dn records and fails
-- as it should.
Removing the assertion provides for the expected behavior in my simple case.
Basically, it appears that a Base-DN is not being pre-filtered by the Back-SQL
selection search, so it needs to be filtered by the dnIsSuffix check.
While I could certainly see that my metadata is not correct (stock metadata from
2.3 + changes from 200511/msg00504.html) I'm not sure an assert(0) is
appropriate.
Additionally, there's no indication that back-sql can't support data with
multiple DNs.
Actually, your assumption is partially incorrect, since back-sql doesn't
do prefiltering of the DN if the search is rooted at the database's
suffix (it's called the "subtree shortcut") unless you tell it
otherwise, by using "use_subtree_shortcut no" (the docs state it's the
default; this is wrong).
I admit assert(0) there is a bit too strong, but I believe it was put
there to catch this type of problems. I think the "right" solution,
apart from fixing the docs, consists in removing the assertion.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------