[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.


Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it