[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problem with back-sql and has_ldapinfo_dn_ru

Andrew Gray wrote:

I have a Debian system, installed OpenLDAP 2.2.23 from the Debian apt
repository (version 2.2.23-5), and installed a local version of
PostgreSQL 8.0.1, compiled from source.  OpenLDAP and PostgreSQL are
both working fine except for one minor issue:

I am trying to optimize our setup by enabling and using the dn_ru fields
to eliminate the overhead of using upper(dn) in queries to Postgres. I
have my ldap_entries table set up as:

CREATE TABLE ldap_entries
(
 id int4 NOT NULL,
 dn varchar(255) NOT NULL,
 dn_ru varchar(255) NOT NULL,
 oc_map_id int4 NOT NULL,
 parent int4 NOT NULL,
 keyval int4 NOT NULL,
 CONSTRAINT ldap_entries_id_key UNIQUE (id)
)

And in my /etc/ldap/slapd.conf file:
database        sql
suffix          "dc=somewhere,dc=com"
dbname          PostgreSQL
dbhost          localhost
dbuser          "xxx"
dbpasswd        "yyy"
upper_func      "upper"
strcast_func    "text"
concat_pattern  "?||?"
has_ldapinfo_dn_ru      yes
lastmod         off

Running slapd -d 65535 and grepping for dn_ru:
line 99 (has_ldapinfo_dn_ru yes)
<==backsql_db_config(): has_ldapinfo_dn_ru=yes

But slapd continues to use upper(dn) in queries to Postgres (as shown in
the Postgres server log and slapd's debug log).

I've googled around for info, but just find everyone turning
has_ldapinfo_dn_ru off - does this feature not work or am I missing
something simple?



I haven't tested it for a long while, so I'd consider it essentially not working: there's no code to maintain the uppercased DN when writes ocur via back-sql, and things like that. I'm inclined to removing that option in future versions to reduce complexity, since performances are not the primary goal of back-sql.

p.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497