[Date Prev][Date Next]
Re: ldap_entry_objclasses and attribute mappings with back-sql
> On Sun, 2004-03-07 at 10:49, Guenther Starnberger wrote:
>> Somehow i am not able to return custom attributes for classes defined
>> as ldap_entry_objclasses with back-sql.
> Hmmm.. the cause of the problem seems to be in the SQL queries which are
> ie. one query with a WHERE clause of ldap_entries.oc_map_id=101 (which
> is a posixAccount) AND (upper('posixAccount')='POSIXACCOUNT'), which
> doesn't find anything because this oc_map_id isn't a posixAccount but an
> another query with a WHERE clause of ldap_entries.oc_map_id=1 (which is
> an inetOrgPerson) AND (upper('inetOrgPerson')='POSIXACCOUNT').
> Is this a configuration error or a bug in OpenLDAP?
neither. In recent versions of back-sql, I made candidate
selection a bit liberal, because for very complex queries,
there is the possibility that back-sql is not able to
generate a where clause that corresponds to the LDAP filter
in an exact manner; so I try to make the where clause at
worst a superset of the LDAP filter, and delegate filter
testing to slapd's frontend, so that entries that don't
match the filter are simply discarded. That guy hit the
same problem you did, because an attempt to generate an
entry whose objectclass doesn't contain a certain attribute
was causing a core dump. Now that it's fixed, the server
will generate the entry correctly, without the attributes
it doesn't contain, and the frontend will reject it because
the attribute used in the filter is not available. It's
a trade-off; as soon as we find better ways to generate more
accurate filters this will happen less and less.