[Date Prev][Date Next]
Re: unique values
- To: Quanah Gibson-Mount <email@example.com>, "A. Schulze" <firstname.lastname@example.org>, email@example.com
- Subject: Re: unique values
- From: Howard Chu <firstname.lastname@example.org>
- Date: Tue, 7 Mar 2017 16:58:34 +0000
- In-reply-to: <WMemail@example.com>
- References: <20170306163711.Horde.gRGGxzEzzV6O8YvS8PNBOuO@andreasschulze.de> <WMfirstname.lastname@example.org> <06C3BC1193844B9710E2F192@[192.168.1.30]> <WMemail@example.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46a2
Quanah Gibson-Mount wrote:
--On Monday, March 06, 2017 4:37 PM +0100 "A. Schulze" <firstname.lastname@example.org>
while planning a data scheme update we found it handy to have a unique
value for each entry.
short time later we found "entryUUID" :-)
But we are still unsure.Should we simply use entryUUID or should we
extend our schema
to hold a new attribute similar to entryUUID.
entryUUID is defined in RFC4530, as an internal LDAP attribute. Personally, if
you need a UUID for tracking, I would create your own specific to your
application/needs. For example, when I was at Stanford, we used suRegID
(stanford university registry ID) and when I was at zimbra, we used zimbraID
(zimbra identifier). There have been format changes in the past that required
wiping out some of the generated attributes when going between releases.
This is bad advice. If you actually want a UUID then use entryUUID. As noted,
it is defined in RFC4530 which means it isn't going to change. The format of
UUIDs is well-established in internet standards.
When an existing attribute has *exactly* the syntax and semantics that you
want, use it.
suRegID and zimbraID are not UUIDs are they?
Using your own identifier ensures that will not be an issue. Also, if you do
things like allow backing up/restoring user entries that have gotten deleted,
a restored entry (depending on the method use) may end up with a new entryUUID.
Yes, you should only use the recommended backup procedures.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/