Also known as "Universal(ly) Unique Identifier" (UUID).
There are no builtin functions, but there are modules, including Data::UUID.
| [reply] |
Also, Win32API::GUID if you're on MSWin32.
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
| [reply] |
Also, MySQL has a uuid() function now which you can call. | [reply] |
There's DBIx-Sequence. I think there's another module that increments a number in a file. | [reply] |
$ctx = Digest::MD5->new;
$ctx->add($token);
my $uuid = $ctx->hexdigest;
where $token is a piece of text that is unique to the way we do things so we can get a UUID in a reproducable manner. That is, if we want to get the UUID for the same object multiple times (say across invocations of the code), we come up with the same token. By coming up with the same token each time, we get the same UUID each time. That is important to us. If you just want a unique UUID each time you call, you can create a random token, feed it in, and you'll get a unique UUID - Data::UUID uses the current time as part of the seed to this generation process. | [reply]
[d/l] |
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 ]
| [reply] |
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] |