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

RE: Multiple Objectclass in Backend SQL

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