directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: [SchemaService]
Date Sat, 20 Jan 2007 07:03:43 GMT

As handling methods of most of the situations have been addressed I
want to discuss the algorithms for Collective Attributes handling.

Case 1: Entry Addition

Besides other controls;
IF 'objectClass' list includes 'collectiveAttributeSubentry'
   Allow any (collective) attribute to be added with the entry
   Deny entry addition if it contains any collective attribute

Collective attributes can be physically stored only in subentries of
type collectiveAttributeSubentry. As a collective attributes is
flagged to be collective in the schema definition of the attribute, it
can be easily checked whether an attribute is collective or not using
the isCollective() method in our API.

Case 2: Entry Modification

Besides other controls;
IF the new state of the entry contains collectiveAttributeSubentry as
an objectClass value
   Allow any collective attributes which were already present in the
entry to remain as are
   and allow any new collective attributes being added.
   Do not allow any remaining collective attributes in the entry
(which may be a collective attribute subentry formerly) and do not
allow any collective attributes to be added via ADD or REPLACE mods.

Although these lines are not so long, in the schema service these
checks cost lots of code and attention to be payed. I had implemented
the first case but was blocked for the second case. I will give them a
second try soon.

On 1/20/07, Emmanuel Lecharny <> wrote:

> Special cases are like collective attributes, extensibleObject objectclasses, operational
attributes, top, are supposed to be handled correctly.
> Any ideas, comments, insight ?
> Thanks !
> Emmanuel


View raw message