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

RE: Multiple Objectclass in Backend SQL

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.


--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.



At 05:07 PM 3/26/2002, you wrote:


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.