I find that if I `replace' the values of objectClass, its order moves to the end of the attribute list -- like,
$ ldapsearch ... dn: ... objectClass: top attributeOne: ...
$ ldapmodify dn: ... changetype: modify replace: objectClass objectClass: top
$ ldapsearch ... dn: ... attributeOne: ... objectClass: top
I don't that I have ever seen objectClass appear anywhere but at the top of the entry, before this. Evidently it isn't a serious problem - these entries are still retrievable, modifiable and slapadd works on them.
I personally would prefer to avoid it anyway, but I'm not the one who's been doing it. Anyone know of undesirable consequences if objectClass moves to a location other than the first attribute?
thanks! Donn Cave, donn@u.washington.edu
On Wed, 14 Feb 2007, Donn Cave wrote:
[...]
I don't that I have ever seen objectClass appear anywhere but at the top of the entry, before this. Evidently it isn't a serious problem - these entries are still retrievable, modifiable and slapadd works on them.
Order doesn't matter, but current behaviour seems to be first in first out or something, thus when you modify an attribute it propagates to the end of the list.
Yeah, it looks funny, but end users aren't supposed to "see" raw LDIF.
Dave Horsfall wrote:
On Wed, 14 Feb 2007, Donn Cave wrote:
[...]
I don't that I have ever seen objectClass appear anywhere but at the top of the entry, before this. Evidently it isn't a serious problem - these entries are still retrievable, modifiable and slapadd works on them.
Order doesn't matter, but current behaviour seems to be first in first out or something, thus when you modify an attribute it propagates to the end of the list.
Additionally any client or server implementation relying on some kind of attribute order or attribute value order is broken. And the order in the LDIF does not necessarily say anything about the order in the internal representation or the order in the LDAPResult message.
Yeah, it looks funny, but end users aren't supposed to "see" raw LDIF.
Yupp. No problem at all if the clients are not broken.
Ciao, Michael.
Michael Ströder wrote:
Dave Horsfall wrote:
On Wed, 14 Feb 2007, Donn Cave wrote:
I don't that I have ever seen objectClass appear anywhere but at the top of the entry, before this. Evidently it isn't a serious problem - these entries are still retrievable, modifiable and slapadd works on them.
Order doesn't matter, but current behaviour seems to be first in first out or something, thus when you modify an attribute it propagates to the end of the list.
Additionally any client or server implementation relying on some kind of attribute order or attribute value order is broken. And the order in the LDIF does not necessarily say anything about the order in the internal representation or the order in the LDAPResult message.
Yeah, it looks funny, but end users aren't supposed to "see" raw LDIF.
Yupp. No problem at all if the clients are not broken.
This all comes down to knowing the specs. The X.500 data model defines an "entry" as a SET of attributes. A set is a well-defined mathematical concept; the two key properties here are that there is no ordering of a set's members, and an element can only appear once in a set. Thus, the ordering of attributes in an entry is essentially random, and an attribute can only appear once in an entry.
Likewise an "attribute" is defined as a SET of values. Once again, no ordering, and any value can only appear once in an attribute.
When you know the underlying definitions, everything else is obvious. When you try to use LDAP without knowing the underlying definitions, you tend to get yourself into trouble.
openldap-software@openldap.org
-
Dave Horsfall -
Donn Cave -
Howard Chu -
Michael Ströder