Having meta-information loaded, the SQL backend uses these tables
to determine a set of primary keys of candidates (depending on
search scope and filter). It tries to do it for each objectclass
registered in ldap_objclasses.
Example: for our query with filter (telephoneNumber=123*) we
would get the following query generated (which loads candidate
IDs)
SELECT ldap_entries.id,persons.id, 'person' AS objectClass,
ldap_entries.dn AS dn
FROM ldap_entries,persons,phones
WHERE persons.id=ldap_entries.keyval
AND ldap_entries.objclass=?
AND ldap_entries.parent=?
AND phones.pers_id=persons.id
AND (phones.phone LIKE '%1%2%3%')
(for ONELEVEL search) or "... AND dn=?" (for BASE search) or "...
AND dn LIKE '%?'" (for SUBTREE)
Then, for each candidate, we load the requested attributes using
per-attribute queries like
SELECT phones.phone AS telephoneNumber
FROM persons,phones
WHERE persons.id=? AND phones.pers_id=persons.id
Then, we use test_filter() from the frontend API to test the
entry for a full LDAP search filter match (since we cannot
effectively make sense of SYNTAX of corresponding LDAP schema
attribute, we translate the filter into the most relaxed SQL
condition to filter candidates), and send it to the user.
ADD, DELETE, MODIFY and MODRDN operations are also performed on
per-attribute meta-information (add_proc etc.). In those fields
one can specify an SQL statement or stored procedure call which
can add, or delete given values of a given attribute, using the
given entry keyval (see examples -- mostly PostgreSQL, ORACLE and
MSSQL - since as of this writing there are no stored procs in
MySQL).
We just add more columns to ldap_oc_mappings and
ldap_attr_mappings, holding statements to execute (like
create_proc, add_proc, del_proc etc.), and flags governing the
order of parameters passed to those statements. Please see
samples to find out what are the parameters passed, and other
information on this matter - they are self-explanatory for those
familiar with the concepts expressed above.
