RE: Multiple Objectclass in Backend SQL

[Thomas Cramer <cramert@musc.edu>]

I know this is an older post, I don't always keep up with the list and kind 
of sort through it every couple months.  I am currently using back-sql 
patch utilizing a sybase database in production.  I also encountered this 
problem.  I ended up having to re-write some of the functions to fix this. 
My fixes are a bit crude.  Around the time I did this (6 months ago?) there 
didn't seem much interest in back_sql.  If you are interested, or anyone 
else that reads this, you can email me and I'll explain what I did (and of 
course share the code).  I didn't submit the changes because I wasn't (and 
am not) currently working with the HEAD.  Also I wanted to find a few 
others actually using back_sql to check the resonablesness of the changes.

==
tc

--On Wednesday, March 27, 2002 9:56 AM +0800 Nemo Tse 
<nemo@nemoathome.ods.org> wrote:

> Thanks a lot Dmitry.
>
> However still got a problem that if the attribute is included in the
> specified objectclass, it will not be processed at all.  Say for example,
> the gn attribute will be simply skipped if the objectclass is
> inetOrgPerson, as used in the back-sql sample.  Unless I modify the
> inetOrgPerson schema in slapd.conf.
>
> In contrast the search mechanism does work well with that.  It looks up
> the ldap_attr_mappings table and search for and process all attributes
> matched the specified/associated objectclass.  Thus virtually processed
> multiple objectclasses.
>
> I wonder why the backsql_add() wasn't wrote in the same manner as the
> query mechanism.
>
> Regards,
>
> Nemo.
>
> At 05:07 PM 3/26/2002, you wrote:
>
> > Hello!
> >
> > As far as I can remember, back-sql supports one objectclass MAPPING per
> > object, but multiple objectclasses. It uses first
> > objectClass value to determine what mapping to use, and adds other as
> > common attributes. So, from LDAP's point of view, the
> > returned objects truly have multiple objectclasses.
> > You can define a mapping that includes attributes of all objectclasses
> > you  need in one object - there is no need to follow LDAP
> > schema exactly, your mapping for an objectclass can include more
> > attributes than defined in LDAP schema...
> >
> >
> > WBW, Dmitry
> >
> > > ----- Original Message -----
> > > From: "Nemo Tse" <nemo@nemoathome.ods.org>
> > > To: <openldap-software@OpenLDAP.org>
> > > Sent: Friday, March 15, 2002 9:21 PM
> > > Subject: Multiple Objectclass in Backend SQL
> > >
> > > ...
> > > >
> > > > However I encountered a symptom that the Backend-SQL do not handle
> > > multiple
> > > > objectclass in an entry.  It will only take the first appearance of
> > > > "objectclass" as objectclass and any "objectclass" afterward will be
> > > > treated as attributes.
> > > >
> > > > I had define two objectclasses in the same entry.  The
> > > first objectclass
> > > > was processed perfectly.  The second objectclass line were reported
> > > > "attribute not registered with this objectclass".
> > > >
> > > > If I reverse the position of the two objectclass, the first
> > > appeared one
> > > > still been processed without any problem.  The second one
> > > still error with
> > > > "not registered".
> > > >
> > > > I believed the db-schema and query/entry statements are
> > > correct as they
> > > > work properly with a single objectclass entry.
> > > >
> > > > The db-schema seems to me that it can support multiple
> > > objectclasses, to
> > > > some extend it is not, e.g. the objectclass id is tied
> > > within the entry
> > > > record, however it should be still workable.
> > > >
> > > > I had also looked into the source ( backsql_add() ) and
> > > seems to me that
> > > it
> > > > has only been called once during a add entry process.  And within
> > > > backsql_add() it seems only handle a single objectclass-tree.
> > > >
> > > > Appreciate any comment or hints.
> > > >
> > > > Nemo.
> > >
> > >