[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SQL backend SELECT problem (1=1 causes horrible performance)
On Fri, 2006-02-17 at 17:13 +0100, Jakob Ãstergaard wrote:
> Pierangelo Masarati wrote:
> >> I'm using 2.2.23 (from Debian Sarge)
> >
> > In any case, note that OpenLDAP 2.2 itself is historic; 2.2.23 is not the
> > latest release of OpenLDAP 2.2; and back-sql is known to be flawed in the
> > 2.2 series (and in 2.3 up to 2.3.14, I believe). So upgrading to the
> > latest 2.3 is strongly recommended for many reasons, but particularly if
> > you intend to use back-sql. If the issue persists, we can try to work the
> > actual reason out and, if possible, provide a fix or a workaround (like
> > allow to disable a feature in slapd.conf when desirable).
>
> I upgraded to 2.3.19, and ran into the following problem;
>
> My person records in the SQL backend use a DN on the form
> uid=XXX,ou=contacts,cn=evalesco,cn=com
>
> The SQL query generated for an ldapsearch like in the original mail now
> looks like:
>
> SELECT id,keyval,oc_map_id,dn
> FROM ldap_entries
> WHERE upper(dn)=upper('ou=contacts,dc=evalesco,dc=com')
>
> Meaning, it does not retrieve *any* records at all, because all records
> have a uid=XXX prefix in the DN. (The ldap_entries is a view that
> returns the DN from the person records - I assume this is the correct
> way to do things).
OK, you hit the "it's a view" bug. For some reason, the search base has
to be retrieved, so, if you use a simple view, typically that doesn't
resolve to an existing entry. You should try the "baseObject"
directive. See slapd-sql(5) for details.
p.
Ing. Pierangelo Masarati
Responsabile Open Solution
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@sys-net.it
------------------------------------------