Hallvard B Furuseth wrote:
Howard Chu writes:
> This is the first stage in a larger transition, to using sorted arrays
> for multivalued attributes. I haven't quite decided how the next steps
> will play out just yet.
> We can also implement this without any user-visible change, if we keep
> an auxiliary ordering array, the way the current sorter does. But it
> seems to me that that will be too much memory overhead. It also makes
> add/remove that much more tedious...
Add a slapd.conf directive which inserts an implicit X-ORDERED 'VALUES'
in an already existing attribute definition. Then admins can configure
the old behavior for the attributes where he needs it, including in
preexisting schema. (Could support @objectclass and !objectclass to
list multiple attributes, or a regex matching the attribute name.)
OK, that makes sense. Except it's not the same as X-ORDERED 'VALUES' behavior.
The X-ORDERED properties allow you to define an arbitrary static ordering.
This is just a straight memcmp-based ordering (or similar, most likely
I don't think objectclass shorthand makes sense here. It would be pretty
unusual to need this feature on e.g. all the attributes of inetOrgPerson.
This would be somewhat like integrating the valsort overlay features into the
mainline (but without the weighted option).
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/