Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
LDAP-96: The order of a multi-valued attribute is not preserved by modifyAttributes(DirContextOperations) #136
As an example, consider two values of attribute “title”: [“Juergen”, “George”].
In my mapToContext method I do something like:
context.setAttributeValues(“title”, values, true), // order matters
where values now contains [“George”, “Juergen”], i.e., the values have been permuted.
After the update, fetching the new values using adapter.getStringAttributes() shows that the values are in the wrong, original order.
Quite right, ordering was not taken into consideration when calculating the @ModificationItem@s. Added this as a special case in
Brian Relph said:
Unfortunately, I don’t think that LDAP can be used to store ordered attributes, if I understand the specification [ http://www.ietf.org/rfc/rfc2251.txt ] correctly:
…Each attribute value is distinct in the set (no duplicates). The order of attribute values within the vals set is undefined and implementation-dependent, and MUST NOT be relied upon.
Jürgen Failenschmid said:
Other functions of Spring LDAP rely on ordering of attributes, otherwise the order-related features wouldn’t be there at all.
The blurb of RFC2251 about “must not rely” upon the ordering of attribute values needs to be read in the context of “is undefined and implementation-dependent”. The RFC does not mean that an LDAP implementation could not provide deterministic ordering of attributes.