[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ldap
Subject:    [ldap] Re: Modify Multivalued Attribute
From:       Howard Chu <hyc () symas ! com>
Date:       2004-06-16 6:21:57
Message-ID: LYRIS-886202-769805-2004.06.16-02.22.05--ldap#progressive-comp.com () listserver ! itd ! umich ! edu
[Download RAW message or body]

> From: Tod Thomas <tthomas@chubb.com>
> Date: Tue, 15 Jun 2004 16:04:35 -0400

> So, is there something 'special' about ACI attributes that allows them
> to behave as regular attributes (as it pertains to order) when they are
> modified via LDIF, and retain their order when modifying them in the
> configuration file?  If not, and they do behave arbitrarily (as it
> pertains to order) as other attributes do, will my solution above that
> involves deleting and redefining the lot of them, eventually fail as
> they are eventually, arbitrarily, evaluated out of order?

There is nothing that preserves the order that ACI attribute values are 
stored in LDAP; they have the same (lack of) ordering guarantees as for 
all other attributes. What's "special" about ACIs is that they have an 
ordering index encoded into the actual values themselves, so that the 
ACI processor can extract all the values and then sort them into the 
intended order. (Note that this is a kludge, hijacking the OID field of 
the ACI value...)

I've been working on an attribute syntax for OpenLDAP that goes along 
the same basic ideas:
   values are optionally prefixed with "#INDEX#" where "INDEX" is an 
integer specifying the order of the values.
   search, compare, and modify operations can assert just the "#INDEX#" 
part, or just the value part, or both.

The assertion semantics means you can issue a Modify request like
    modify: orderedAttribute
    delete: #2#
to delete the 2nd value, whatever it happens to be.

But unlike the ACIs which have statically encoded indices, the indices 
here are dynamic. Thus, if you have an attribute
   orderedAttribute: #0#first value
   orderedAttribute: #1#second value
   orderedAttribute: #2#third value

and issue the previous Delete modification, it will automatically 
renumber itself:
   orderedAttribute: #0#first value
   orderedAttribute: #1#third value

If you Add a value without an Index specifier, it is just appended to 
the end of the ordered list. If you Add a value with an Index specifier, 
it is inserted in front of that position in the list.

The sticky part of defining this syntax is when to perform the 
renumbering; if you have a lot of Adds and Deletes in a single Modify 
operation it gets messy.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.       Director, Highland Sun
   http://www.symas.com               http://highlandsun.com/hyc
   Symas: Premier OpenSource Development and Support

---
You are currently subscribed to ldap@umich.edu as: [ldap@progressive-comp.com]
To unsubscribe send email to ldap-request@umich.edu with the word UNSUBSCRIBE as the \
SUBJECT of the message.


[prev in list] [next in list] [prev in thread] [next in thread]