I want to use the entryDN attribute as a unique identifier. Is there any particular reason why I can't read this attribute using openldap.org's server? It won't return in searches I do.
thanks
Brandon McCombs writes:
I want to use the entryDN attribute as a unique identifier. Is there any particular reason why I can't read this attribute using openldap.org's server? It won't return in searches I do.
entryDN is an operational attribute, so it is only returned if you explicitly ask for it in the search request. E.g.
ldapsearch -xLLL -h ldap.uio.no -b "dc=uio,dc=no" -s base "*" entryDN
Am 21.02.2007 um 11:46 schrieb Hallvard B Furuseth:
Brandon McCombs writes:
I want to use the entryDN attribute as a unique identifier. Is there any particular reason why I can't read this attribute using openldap.org's server? It won't return in searches I do.
entryDN is an operational attribute, so it is only returned if you explicitly ask for it in the search request. E.g.
ldapsearch -xLLL -h ldap.uio.no -b "dc=uio,dc=no" -s base "*" entryDN
Besides, for an unique identifier, what suites better entryUUID or entryDN ?
I plan to write an search interface and was thinking about tracking results ...
Many thanks
P.M.
P. Martinez wrote:
Besides, for an unique identifier, what suites better entryUUID or entryDN ?
A DN is supposed to be unique at a given time; the entryUUID is supposed to be unique forever. So, two entries with the same DN could exist at different times (e.g. an entry is deleted and another entry with the same DN is created later on; they are supposed to have different entryUUID because in fact they're different entries). At the same time, an entry could have different DN at different times while keeping the same entryUUID (e.g. an entry is renamed, so the DN changes over time, but the entry remains the same, and thus the entryUUID remains the same as well).
I plan to write an search interface and was thinking about tracking results ...
entryUUID is a perfect key, since it has the above properties and it's fixed length. However, in general it's not something an interface would expose.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati@sys-net.it ------------------------------------------
Pierangelo Masarati writes:
I plan to write an search interface and was thinking about tracking results ...
entryUUID is a perfect key, since it has the above properties and it's fixed length.
Also he doesn't need to parse it if he wants to know if the directory would consider two values equivalent. Unlike how DN "CN=Foo+UID=bar" matches "uid=bar+cn=foo".
However, in general it's not something an interface would expose.
Am 22.02.2007 um 21:50 schrieb Hallvard B Furuseth:
Pierangelo Masarati writes:
I plan to write an search interface and was thinking about tracking results ...
entryUUID is a perfect key, since it has the above properties and it's fixed length.
As i supposed entryUUID is my key. It will be easy being attached to an modified entry for redisplaying it.
Also he doesn't need to parse it if he wants to know if the directory would consider two values equivalent. Unlike how DN "CN=Foo+UID=bar" matches "uid=bar+cn=foo".
Thanks for your opinions
P.M.
openldap-software@openldap.org
-
Brandon McCombs -
Hallvard B Furuseth -
P. Martinez -
Pierangelo Masarati