Hi, 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 ELSE 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. ELSE 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 <[EMAIL PROTECTED]> wrote:
Special cases are like collective attributes, extensibleObject objectclasses, operational attributes, top, are supposed to be handled correctly. Any ideas, comments, insight ? Thanks ! Emmanuel
-- Ersin
