Avoid the common mistake of expecting attribute values in an LDAP search result to be ordered. The LDAP standard explicitly notes that attributes and attribute values are not ordered. Too often, programmers expect data to be ordered, that is, for the order that data is returned from a search request to be repeatable. If the order is important, a directory server such as UnboundID’s Directory Server supports the server-side sort request control.
The ordering also applies to the case where software expects that the order attributes are returned is the same as the order in which they are listed. For example, if the following command is executed in a shell or perl script:
ldapsearch [connection options] search-filter attr1 attr2 attr3
programmers must not expect that the attributes are returned in the order
attr1 attr2 attr3
Further, the order of attribute options is not significant, for example:
is the same as:
It is telling that the standard specifically mentions that attribute values (and partial attribute values) are not ordered, rather than leaving it up to the vendor. Several times per year a case comes up where a programmer written some code that is dependent on the ordering of attributes and this code suddenly – for no apparent reason – stops working. The code “used to work” or “has worked for years”. The reason was that the code was dependent on the ordering of attributes, attribute values, return order, or entry ordering. it is also important to note that the ordering is not repeatable, that is, the ordering could conceivably change from one search request to the next.