Re: Questions about back-sql

[Pierangelo Masarati <ando@sys-net.it>]

Nikola Ivancevic wrote:
> Pierangelo Masarati wrote:
>
> > > > > I understand that back-sql implements only a subset of functionality
> > > > >        
> > > > but  I have expected, reading the back-sql manual, that a ldapsearch
> > > > query  with a filter for objectclass values works correctly.
> > > > Then, can you provide a complete example of what you're trying to do,
> > > > including rdbms you're using, what data, what back-sql mapping,
> > > > and so, and a clear description of the operation (a search, I assume)
> > > > you're trying to perform?  Finally, what software version?
> > > >      
> > > This feature does not work, at least not for me.
> > > back-sql recipe -
> > > ftp://ftp.kalamazoolinux.org/pub/projects/awilliam/misc-ldap/ogo-back-sql-create.sql
> > > - using OpenLDAP 2.1.25
> > >
> > > Although all "account" objectclass's also have an auxilliary objectclass
> > > of "opengroupwareentity" (so I can provide the opengroupware primary key
> > > ID) searching by that objectclass does not work.
> > >
> > > Otherwise back-sql works great,  lets people with applications like
> > > Eudora or Evolution pull data from the RDBMS, which is just cool beyond
> > > words.
> > >    
> >
> > I have an enhancement for back-sql, that honors searches
> > on objectClass superiors, e.g. if you defined an objectClass
> > "inetOrgPerson", a search for "objectClass=person" returns it.
> >
> > It's not exactly what you need, I guess, but it's part of it.
> > The same could apply to attribute inheritance.
> >
> > I'll commit it to HEAD ASAP, together with some more cleanup.
> >
> > Ando.
> >
> >  
> Thank you for your effort to implement this feature of back-sql.
> In order to perform such a search, do I have to insert a record for 
> 'person' objectclass into ldap_entry_objclasses and bind it with 
> inetOrgPerson (or the schema definition is sufficient for the search)?
> If I have to, do I have to populate appropriate records for 'person' 
> objectclass within ldap_attr_mappings and ldap_oc_mappings?

No, the schema definition suffices.  Unfortunately, the "improvement"
I committed recently partially breaks the "ldap_entry_objclasses"
handling, but I already fixed this as well (commit in a few hours).

Now:
- the "structural" objectclass for an entry, the one defined
  in the schema definition, can be searched also by its ancestors
- other objectclasses can be defined on an entry's basis
  (e.g. oc_name-entry_id mapping) via the "ldap_entry_objclasses"
  table; these are honored in searches and their ancestors are
  as well
- multiple attribute definitions can be provided in the schema
  for a single objectclass; in searches, they are all honored.
  so one could define multiple "cn" instances for each entry
  based on different sources, and search for them or retrieve
  all or part of them (e.g. "cn=Mitya Kovalev" and "cn=Mitya"
  respectively defined as "name||' '||surname" and "surname").
  The only limitation is that writes (add, update, delete, modrdn)
  only honor the first definition of an attribute.
- don't use this feature to add objectclasses; use the
  "ldap_entry_objclasses" instead, possibly via a "view" to
  combine specific per-entry data and common (or rule-based)
  multiple objectClass definitions.
- filtering for objectClass is much more efficient than earlier:
  if one searches for the schema objectClass or one of its
  ancestors, candidate selection doesn't even get to the RDBMS.

There's still a lot to do, but I think back-sql is getting
more and more LDAP compliant.

p.

--
Dr. Pierangelo Masarati         mailto:pierangelo.masarati@sys-net.it
LDAP Architect, SysNet s.n.c.   http://www.sys-net.it



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