Re^2: Function to create a GUID

That looks like a really bad idea. GUIDs and UUIDs are supposed to be globally or universally unique. You should not try to "generate" matching identifiers, ever. Ask for an identifier once and immediately associate it globally, permanently, indelibly, invariably, undeniably, universally, with the entity in question. If another party/player/machine/database needs to know the identifier of that entity, it should ask the entity or registrar of entities, it should not just "generate" something that "should" match it.

A GUID or UUID is typically generated a priori without any knowledge of the entity to which it will be associated. That's so you can have a huge supply of identical entities and they all get unique individual identifiers. Tokens could somehow match, and then these hash-up identifiers would match. If you already have a "token" (your word) which is unique for the object, then you don't need a GUID/UUID hashing of it: use that token as your identifier.

--
[ e d @ h a l l e y . c c ]

Comment on Re^2: Function to create a GUID

Replies are listed 'Best First'.
Re^3: Function to create a GUID by Tanktalus (Canon) on Sep 23, 2005 at 19:03 UTC
I really disagree. Just because a GUID or UUID is typically done one way doesn't mean that's the only good way to do it. We would love to use our token instead of the UUID. In our (undereducated?) opinions, UUIDs are fossils of a past era in computing and should be completely and utterly destroyed without prejudice. However, the application for which we were generating these took both tokens and UUIDs, and would not proceed without both. (We have an open requirement against them to abandon UUIDs - we'll see when/if that happens.) So, until such a time as they abandon inferior technology, we're stuck. Our problem was one of scope: we needed thousands of UUIDs, and we needed some way to not only keep them matched across invocations, but to automatically be added when needed, removed when no longer needed, and every single one would need to be changed when we changed versions. Without failure. Since we're sometimes adding 7 or 8 at a time, other times we're adding 100-200 at a time, and then when we change versions, we're changing all 1200+ of them, we felt that it was significantly better to use Data::UUID's 'create_from_name' approach to come up with these UUIDs, and instead come up with a way to map all relevant information, including version number, into a token which we could feed into the digest to come up with our hash. Of course, the other problem was that the entities were purely virtual without that token, and there was/is no registrar to ensure that our use of this application did not collide with other users of the application. Not much we could do about that that I can see.	[reply]

Replies are listed 'Best First'.

Re^3: Function to create a GUID
by Tanktalus (Canon) on Sep 23, 2005 at 19:03 UTC

I really disagree. Just because a GUID or UUID is typically done one way doesn't mean that's the only good way to do it.

We would love to use our token instead of the UUID. In our (undereducated?) opinions, UUIDs are fossils of a past era in computing and should be completely and utterly destroyed without prejudice. However, the application for which we were generating these took both tokens and UUIDs, and would not proceed without both. (We have an open requirement against them to abandon UUIDs - we'll see when/if that happens.) So, until such a time as they abandon inferior technology, we're stuck.

Our problem was one of scope: we needed thousands of UUIDs, and we needed some way to not only keep them matched across invocations, but to automatically be added when needed, removed when no longer needed, and every single one would need to be changed when we changed versions. Without failure. Since we're sometimes adding 7 or 8 at a time, other times we're adding 100-200 at a time, and then when we change versions, we're changing all 1200+ of them, we felt that it was significantly better to use Data::UUID's 'create_from_name' approach to come up with these UUIDs, and instead come up with a way to map all relevant information, including version number, into a token which we could feed into the digest to come up with our hash.

Of course, the other problem was that the entities were purely virtual without that token, and there was/is no registrar to ensure that our use of this application did not collide with other users of the application. Not much we could do about that that I can see.

[reply]