This brings up something I've been pondering for a while with regards to the predictability of using UUIDs.
Back in early versions of MSSQL7, the newid() function would return predictable results when called consecutively. It appears that Data::UUID also does the same.
Here's a quick run using create/to_string:
#!/usr/bin/perl -w -T
use Data::UUID;
use strict;
my $uuidgen = Data::UUID->new;
for (1..5) {
my $uuid = $uuidgen->create();
print $uuidgen->to_string($uuid) . "\n";
};
yields
1D888068-1DD2-11B2-AD1E-F3DCB6356242
1D8899D6-1DD2-11B2-AD1E-F3DCB6356242
1D88A142-1DD2-11B2-AD1E-F3DCB6356242
1D88A5F2-1DD2-11B2-AD1E-F3DCB6356242
1D88A994-1DD2-11B2-AD1E-F3DCB6356242
I usually use UUID to guarantee uniqueness, and sometimes in things like ecommerce, you don't want these things to be predictable in a basic effort to prevent end user guessing games. Yes, I know securiyy is much larger than that, but preventing predictable sequential keys for some things help. :-P
If I know the first line above, it's pretty easy to start generating the next 4 through trial and error.
Somewhere along the line, MSSQL7 SP3+ and MSSQL 2K made the output non predictable when running a series
select newid(), newid(), newid(), newid(), newid()
yields
F52C627C-E150-44AB-8CE9-4A4CBFF2C8EE
5E3190A5-670F-491A-A9E4-18E15B0129FD
227533E0-65A2-4668-B7F0-97F7BCC8625F
7C85C050-4956-4E1E-BFFB-2FE6E6378267
AAF3F967-30C3-418B-BD6F-2CC8B8440DD9
So, what changed I wonder, and how can I make Data::UUID behave more like MSSQL2K when generating consecutive uuids?
I tried feeding the previous uuid into the namespace/name of the new uuid during creation and it appears to work.
#!/usr/bin/perl -w -T
use Data::UUID (NameSpace_X500);
use strict;
my $uuidgen = Data::UUID->new;
# Get first random seed uuid
my $uuid = $uuidgen->create();
my $prevuuid = $uuidgen->to_string($uuid);
for (1..5) {
my $uuid = $uuidgen->create_from_name(NameSpace_X500, $prevuuid);
$prevuuid = $uuidgen->to_string($uuid);
print $prevuuid . "\n";
};
yields
997737A7-8390-360A-A356-92B94CC4F6BC
3CA5C37D-B2B7-343F-B1F5-A0F3DAED46F2
21CBBF52-8C16-3AFE-9F40-DCD60825842D
741F2107-D4C1-322C-AEFE-638F63502407
1D47E49F-7568-30D2-9E27-5AF90D407F58
Certainly less predictable.
So, the question becomes: have I sacrificed any randomness or uniqueness by doing this?
-=Chris
|