On Tue, 2005-11-22 at 00:15 +0100, Pierangelo Masarati wrote: > On Mon, 2005-11-21 at 22:40 +0000, Seb James wrote: > > On Mon, 2005-11-21 at 21:29 +0100, Pierangelo Masarati wrote: > > > On Mon, 2005-11-21 at 19:38 +0000, Seb James wrote: > > > > Here is the query which backsql_srch_query() contructs: > > > > > > > > SELECT DISTINCT ldap_entries.id,persons.id,'inetOrgPerson' AS objectClass, > > > > ldap_entries.dn AS dn FROM ldap_entries,persons > > > > WHERE persons.id=ldap_entries.keyval > > > > AND ldap_entries.oc_map_id=? > > > > AND ldap_entries.dn LIKE ? > > > > AND ( LIKE 'MITYA%') > > > > > > this is NOT valid SQL, as far as I can tell. > > > > > > > > > > > The problem is in the last line. I don't know enough sql to tell if this > > > > could be valid sql on another rdbms, but if I change the last line to > > > > > > > > AND (cn LIKE 'MITYA%') > > > > > > > > Then the query will run. > > > > > > That's how it should be. > > I've checked both latest 2.3 and 2.2 and they appear to work as > expected. I note that the empty space where "cn" should appear, is > supposed to contain the "sel_expr" column of the "ldap_attr_mappings" > table of the "cn" row. In the test databases shipped with OpenLDAP it's > supposed to contain > > 2.2: 'persons.name' > > 2.3: "concat(persons.name,' ',persons.surname)" > > Could you check what's the contents of that column in yours? Yes, it seems my db table is correct (for 2.2): -- -- Dumping data for table `ldap_attr_mappings` -- INSERT INTO `ldap_attr_mappings` VALUES (1, 1, 'cn', 'persons.name', '', 'persons', NULL, NULL, NULL, 3, 0); INSERT INTO `ldap_attr_mappings` VALUES (2, 1, 'telephoneNumber', 'phones.phone', '', 'persons,phones', 'phones.pers_id=persons.id', NULL, NULL, 3, 0); INSERT INTO `ldap_attr_mappings` VALUES (3, 1, 'sn', 'persons.name', '', 'persons', NULL, NULL, NULL, 3, 0); INSERT INTO `ldap_attr_mappings` VALUES (4, 2, 'description', 'documents.abstract', '', 'documents', NULL, NULL, NULL, 3, 0); INSERT INTO `ldap_attr_mappings` VALUES (5, 2, 'documentTitle', 'documents.title', '', 'documents', NULL, NULL, NULL, 3, 0); INSERT INTO `ldap_attr_mappings` VALUES (6, 2, 'documentAuthor', 'documentAuthor.dn', '', 'ldap_entries AS documentAuthor,documents,authors_docs,persons', 'documentAuthor.keyval=persons.id AND documentAuthor.oc_map_id=1 AND authors_docs.doc_id=documents.id AND authors_docs.pers_id=persons.id', NULL, NULL, 3, 0); INSERT INTO `ldap_attr_mappings` VALUES (7, 3, 'o', 'institutes.name', '', 'institutes', NULL, NULL, NULL, 3, 0); > > Ok, this is useful information that back-sql has changed a lot between > > openldap 2.2 and 2.3. I'll upgrade my openldap version and see how that > > works. > > I suggest to upgrade anyway. Note that back-sql in OpenLDAP up to > 2.3.11 is buggy because I was unable to test and keep it up to date for > a while, and the rest of slapd underwent some development that broke it; > 2.3.12 should be just fine, I could test it to some extent, at least > with PostgreSQL. I'll get 2.3.12 and test that. Cheers, Seb -- Embedded Software Foundry Ltd. 'Embedded Linux Development' Tel: +44 (0)845 4580277 Web: http://www.esfnet.co.uk/ Axiom Tech Open Source Member: http://www.axiomtech.co.uk/ Gpg key: http://www.esfnet.co.uk/ssl/seb.gpg
Attachment:
signature.asc
Description: This is a digitally signed message part