Comment On GUGUID

« PrevPage 1 | Page 2 | Page 3Next »

Re: GUGUID

2012-08-14 09:13 • by Mijzelf (unregistered)
And how big is the chance to be frist?

Re: GUGUID

2012-08-14 09:13 • by Eilert (unregistered)
Frist?

This is not spam. Or is it?

Re: GUGUID

2012-08-14 09:14 • by lettucemode
Infinite loop?

Re: GUGUID

2012-08-14 09:15 • by Accalia.de.Elementia (unregistered)
okay.... who hacked Remy's account? there are no funny html comments!

Re: GUGUID

2012-08-14 09:19 • by Remy Porter
387160 in reply to 387159
It's hard to work HTML comments into CodeSODs. It's more of a feature article thing. Also, the editor we use for posting articles will eat them if anybody uses IE to edit an article. *ahem*

Re: GUGUID

2012-08-14 09:25 • by toshir0
387161 in reply to 387160
Remy Porter:
Also, the editor we use for posting articles will eat them if anybody uses IE to edit an article. *ahem*
Mark and Alex whistle very casually.

Re: GUGUID

2012-08-14 09:26 • by Accalia.de.Elementia (unregistered)
387162 in reply to 387160
Ah! I found the TRWTF: IE!

Re: GUGUID

2012-08-14 09:31 • by dkf
387163 in reply to 387160
Remy Porter:
Also, the editor we use for posting articles will eat them if anybody uses IE to edit an article.
People use IE for anything? Willingly?

Re: GUGUID

2012-08-14 09:32 • by dgvid
The MSDN documentation for the NewGuid method says only that the chance of a duplicate value is "very low." They should update their docs with the hit-by-a-meteor-during-Lent analogy.

Re: GUGUID

2012-08-14 09:49 • by YR (unregistered)
Where's the WTF? That's totally justifiable! I never felt too comfortable about random values that are this likely to collide.

Cheap bastards, we have plenty of memory and storage capacity, and you use 128 bit random crap?!? We should move to 1 Gbit, at the very least!

Re: GUGUID

2012-08-14 09:50 • by Chelloveck (unregistered)
The API here is TRWTF. You need to call two different GUID generators depending on whether or not this is the first GUID, and you have to keep a list of all your GUIDs around? Who designed this? There should be a single function which takes no parameters and internally stores all the GUIDs it generates. Bonus points if the list of GUIDs is persistent across runs so it can verify that it *never* duplicates a GUID. But that may be outside the scope of this problem.

Re: GUGUID

2012-08-14 09:54 • by Remy Porter
387167 in reply to 387166
Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

Re: GUGUID

2012-08-14 09:56 • by toshir0
387168 in reply to 387165
YR:
Where's the WTF? That's totally justifiable! I never felt too comfortable about random values that are this likely to collide.

Cheap bastards, we have plenty of memory and storage capacity, and you use 128 bit random crap?!? We should move to 1 Gbit, at the very least!
Excessive troll is excessive.

Re: GUGUID

2012-08-14 09:58 • by YR (unregistered)
387169 in reply to 387167
Remy Porter:
Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.


NO WAI!

Re: GUGUID

2012-08-14 10:01 • by Infinite Time and Space (unregistered)
My understanding is the the current date and time is incorporated into the GUID, so no matter what, the context in which this code is used could never have duplicates in the first place. To have a duplicate GUID basically requires two different apps (or threads) on the same machine create a GUID at the same time, and then also be very lucky (or unlucky).

But it is easier to write the code than to read documentation about GUIDs

Re: GUGUID

2012-08-14 10:09 • by Meep (unregistered)
Or you could, you know, use natural keys and avoid all this nonsense.

But that would be too easy, I guess.

Re: GUGUID

2012-08-14 10:11 • by TGV
387173 in reply to 387172
Meep:
Or you could, you know, use natural keys and avoid all this nonsense.

But that would be too easy, I guess.

Above all, it would not be enterprisey!

Re: GUGUID

2012-08-14 10:16 • by Andrew Stein (unregistered)
I hope that none of you ever have the joy of generating GUIDs in parallel using Oracle on AIX.
See Andy Hogg's excellent analysis at
http://sqlfascination.com/2012/01/22/oracle-duplicate-guid-values-being-returned-from-sys_guid-when-run-in-parallel/

Re: GUGUID

2012-08-14 10:19 • by Remy Porter
387176 in reply to 387174
Now that's the real WTF. That's also a reason one of the forums is the "I hate oracle club".

Re: GUGUID

2012-08-14 10:20 • by Sten (unregistered)
I see the problem is that GUIDs are only globally unique. This programmer obviously thought of poor Martians and other extraterrestrials forced to place interplanetary calls to have this fixed (the prices are just insane). On the other hand, he could simply use univerally unique UUIDs :-)

How to generate a _really_ unique guid

2012-08-14 10:20 • by Tim (unregistered)
regular readers will now there's a perfectly simple to ensure your guid is really unique: just take an existing guid and swap the first 2 characters round

http://thedailywtf.com/Articles/A-More-Unique-Identifier.aspx

Re: GUGUID

2012-08-14 10:25 • by She sapped me of my precious bodily guids (unregistered)
GUIDs take up too much space. Use integers:

Guid.NewGuid().ToString().GetHashCode()

Re: GUGUID

2012-08-14 10:26 • by Captcha: opto (unregistered)
387180 in reply to 387167
Remy Porter:
Or, y'know, you could just accept the slim risk that you'll duplicate a GUID sometime before the heat death of the universe. Searching the list of pre-generated GUIDs is going to rapidly turn into a performance bottleneck.

In fact, adding elaborate code like this INCREASES the chance of running into duplicate GUIDS enormously, as it raises the probability of having bugs in it.

Chance of running into a duplicate GUID ≈ chance of having a bug in your code that deterministically generates duplicate GUIDs.

Re: GUGUID

2012-08-14 10:30 • by Shawn H Corey (unregistered)
You because you're not paranoid doesn't mean computers don't hate me!

Re: GUGUID

2012-08-14 10:38 • by rohcQaH (unregistered)
It'll only compare to a small set of GUIDs the caller knows about, not to every other GUID ever issued on this planet.

So it's actually a LUGUID: Locally Unique GUID.

Re: GUGUID

2012-08-14 10:38 • by GettinSadda
The number of random GUIDs (using version 4 which is most common now) there are 2^122 or about 5.3 * 10^36 values.

To put this into perspective the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.

I could calculate the chance of a collision, but I have better things to do :-)

Re: GUGUID

2012-08-14 10:38 • by jim (unregistered)
usually, a system will have a lots of guids, tons of em.
Going through that array of guids each time one needs a new guid is going to eat some serious time. In a smaller system, that might be OK.

In a larger system. If you are adding a new guid pk's row to a table, it might be quicker to jst catch the duplicate pk error and re-assign the guid at that point.

Peace,

Jim

Re: GUGUID

2012-08-14 10:53 • by spike (unregistered)
TRWTF is that this code was written in the first place, it stinks of premature protection. I highly doubt there was an issue that prompted this code to be written.

The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)

Re: GUGUID

2012-08-14 10:59 • by Jason (unregistered)
while driving your Ferrari to the diner for pancakes
I don't eat pancakes for dinner, you insensitive clod!

Re: GUGUID

2012-08-14 11:01 • by GettinSadda
Another way of looking at it, is that there are apparently about 1.33 * 10^50 atoms in the whole planet, and if you were to break the planet down into chunks the size of a grain of sand (about 8 * 10^19 atoms each) you would have about 1.66 * 10^30 grains and could label each of them with a GUID and only use 1/300000th of a percent of the available ones.

Re: GUGUID

2012-08-14 11:05 • by MightyM (unregistered)
387190 in reply to 387179
She sapped me of my precious bodily guids:
GUIDs take up too much space. Use integers:

Guid.NewGuid().ToString().GetHashCode()


Wow, just wow.

(Obligatory Eric Lippert link: http://blogs.msdn.com/b/ericlippert/archive/2010/03/22/socks-birthdays-and-hash-collisions.aspx)

Re: GUGUID

2012-08-14 11:06 • by GettinSadda
387191 in reply to 387187
spike:
The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)

That used to be the case, but according to Microsoft (and the same seems to apply to *nix systems too)
Microsoft:
For security reasons, it is often desirable to keep ethernet addresses on networks from becoming available outside a company or organization. The UuidCreate function generates a UUID that cannot be traced to the ethernet address of the computer on which it was generated. It also cannot be associated with other UUIDs created on the same computer.

Re: GUGUID

2012-08-14 11:06 • by That guy over there (unregistered)
I don't think it's that bad of an idea. The birthday paradox combined with a shitty random number generator could easily result in collisions.

Re: GUGUID

2012-08-14 11:07 • by HERO OF THE GUID (unregistered)
If they had used a more secure GUID they wouldn't have to worry about collisions:

http://rubbishsoft.com/libraries/longguid

FUCK YOU AKISMET YOU FANFARE OF DIARRHEA

Re: GUGUID

2012-08-14 11:12 • by PRMan (unregistered)
387194 in reply to 387187
spike:
TRWTF is that this code was written in the first place, it stinks of premature protection. I highly doubt there was an issue that prompted this code to be written.

The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)


Actually, not anymore. Now they are almost completely random.

I worked at a company where we actually got a duplicate that couldn't be explained any other way except that it was a generated duplicate. This is when I learned that the generation method had changed.

Re: GUGUID

2012-08-14 11:13 • by Esse (unregistered)
I'm having some problem understanding the code.

What if guid3 accidentally gets the same GUID as guid2. The loop first checks if guid3 is the same as guid1. It isn't. Then, it checks if guid3 is the same as guid2. Because it's the same, guid3 gets a new GUID, and the loop ends. But what if the second GUID that's assigned to guid3 is the same as guid1?

Shouldn't the method reloop everytime a new GUID is generated and assigned?

Re: GUGUID

2012-08-14 11:14 • by Some Jerk (unregistered)
He should use a dictionary to increase performance over the .Any() call.

Re: GUGUID

2012-08-14 11:14 • by QJo
387197 in reply to 387185
GettinSadda:
The number of random GUIDs (using version 4 which is most common now) there are 2^122 or about 5.3 * 10^36 values.

To put this into perspective the universe is about 4.6 * 10^17 seconds old, so if a device started calculating 11 billion billion GUIDs a second at the big bang, it would be running out soon.

I could calculate the chance of a collision, but I have better things to do :-)


Running out already? Goodness! We need to sort this one out! Quick, where are my developers? All leave cancelled till you sort this out! GettinSadda has just told me the GUIDs are running out!

Re: GUGUID

2012-08-14 11:16 • by Some Jerk (unregistered)
387198 in reply to 387194
PRMan:
spike:
TRWTF is that this code was written in the first place, it stinks of premature protection. I highly doubt there was an issue that prompted this code to be written.

The perpetrator of this code obviously doesn't understand GUIDs, they have a temporal component (time created), a spatial component (MAC address or similar unique number), a algorithm ID and a random component. (IIRC there may also be a small sequential component intended for GUIDS created at the same time, so even in the unlikely occurrence of a random numbers collision there is still a difference!)


Actually, not anymore. Now they are almost completely random.

I worked at a company where we actually got a duplicate that couldn't be explained any other way except that it was a generated duplicate. This is when I learned that the generation method had changed.
Not this shit again...

Re: GUGUID

2012-08-14 11:16 • by Bananas (unregistered)
387199 in reply to 387166
Chelloveck:
The API here is TRWTF. You need to call two different GUID generators depending on whether or not this is the first GUID, and you have to keep a list of all your GUIDs around? Who designed this? There should be a single function which takes no parameters and internally stores all the GUIDs it generates. Bonus points if the list of GUIDs is persistent across runs so it can verify that it *never* duplicates a GUID. But that may be outside the scope of this problem.
Not good enough. The list of GUIDs it checks against and adds to needs to be in the cloud so that no GUID ever used anywhere in the world/galaxy/universe is duplicate.

Re: GUGUID

2012-08-14 11:23 • by Recursive Reclusive (unregistered)
387200 in reply to 387195
Esse:
I'm having some problem understanding the code.

What if guid3 accidentally gets the same GUID as guid2. The loop first checks if guid3 is the same as guid1. It isn't. Then, it checks if guid3 is the same as guid2. Because it's the same, guid3 gets a new GUID, and the loop ends. But what if the second GUID that's assigned to guid3 is the same as guid1?

Shouldn't the method reloop everytime a new GUID is generated and assigned?

I believe there are two loops in there. An inner loop, "guids.Any(g => g == result)", that goes through all GUIDs and return true or false. And an other loop, "while", that continues until the inner loop return false.

In reality, the inner loop will always return false, so the while-loop is only executed once.

Re: GUGUID

2012-08-14 11:27 • by Slicerwizard (unregistered)
"struck by a meteor and lighting"

Lighting what?

Re: GUGUID

2012-08-14 11:32 • by Some Jerk
As far as real WTFs go... the idea of insuring distinction is perhaps a bit OCD but not uncommon among us home grown developers, where college developers started with facts regarding probability and origins before moving on to code. This isn't a mistake I have made before, but there are times when my comfort level with how the target computer will react to my assumptions causes me insert additional functionality which is not likely to be needed. Either way, I can get behind anything that accounts for Murphy's Law, so although I believe that check to be a bit redundant or (as I said before) OCD, I wouldn't classify THAT part as entirely a WTF.

What I do see as a WTF is the architecture that this coder believes "necessitates" said functionality.This architecture is supporting 3 entities? Or even 3 million, it doesn't matter, though ParamArray may be a silly idea if it is.

If the construct is resident in memory and not serialized, then surely a static incriment structure would work fine. If it is serialized in RDBMS AND necessitates a Guid, then surely the database would be an ideal spot for producting the Guid, and preserving uniqueness. If it is serialized to a file, then would not a date stamp be enough?

My point is... I cannot picture an infrastructure where this implimentation would be useful or necessary.

Re: GUGUID

2012-08-14 11:39 • by Some Jerk
387203 in reply to 387200
Recursive Reclusive:
Esse:
I'm having some problem understanding the code.

What if guid3 accidentally gets the same GUID as guid2. The loop first checks if guid3 is the same as guid1. It isn't. Then, it checks if guid3 is the same as guid2. Because it's the same, guid3 gets a new GUID, and the loop ends. But what if the second GUID that's assigned to guid3 is the same as guid1?

Shouldn't the method reloop everytime a new GUID is generated and assigned?

I believe there are two loops in there. An inner loop, "guids.Any(g => g == result)", that goes through all GUIDs and return true or false. And an other loop, "while", that continues until the inner loop return false.

In reality, the inner loop will always return false, so the while-loop is only executed once.



Not so... :p

guids.Any will return true only if the newly created Guid is already in the ParamArray, and if so, creates a new one. It's basically like replicating SQL In Operator --
if @intVal in (1, 2, 3)
-- yielding true where @intVal is either 1, 2 or 3...

Re: GUGUID

2012-08-14 11:57 • by She sapped me of my precious bodily guids (unregistered)
387204 in reply to 387190
MightyM:
She sapped me of my precious bodily guids:
GUIDs take up too much space. Use integers:

Guid.NewGuid().ToString().GetHashCode()


Wow, just wow.

(Obligatory Eric Lippert link: http://blogs.msdn.com/b/ericlippert/archive/2010/03/22/socks-birthdays-and-hash-collisions.aspx)


Here, this is twice as secure (and a better troll):

Guid.NewGuid().ToString()Guid.NewGuid().ToString() + Guid.NewGuid().ToString()).GetHashCode()

Re: GUGUID

2012-08-14 12:10 • by Cbuttius
Of course it is doing a linear search which ends up being O(N²) to create N guids, and I am assuming this is measured forever, so each time you create a new one you have to check every GUID ever previously created.

It would be interesting to know what they are creating a GUID for. A temp directory / filename is one thing I have used a GUID for. Also for a unique transaction ID in a client-server situation for messaging.

With the temp file, the filesystem will probably check its uniqueness for you. With the messaging system there is almost certainly some kind of lookup map you use because the GUID, which has the letters "ID" in it for a reason, acts as a unique "primary key" for the data underneath. So you will get some kind of error if it already exists without having to go through such a check.

Re: GUGUID

2012-08-14 12:10 • by Canada, eh? (unregistered)
387206 in reply to 387201
Since you're driving, I would assume some kind of roadside lighting. Like a street lamp or billboard floodlight.

Re: GUGUID

2012-08-14 12:10 • by sagaciter (unregistered)
387207 in reply to 387201
Slicerwizard:
"struck by a meteor and lighting"

Lighting what?

If you were struck by a meteor you probably would light.

Re: GUGUID

2012-08-14 12:11 • by Cbuttius
387208 in reply to 387156
Mijzelf:
And how big is the chance to be frist?


I've achieved that aim several times, now I wish to get a comment with a blue background and appearing with the article.

Re: GUGUID

2012-08-14 12:15 • by Cbuttius
387209 in reply to 387192
That guy over there:
I don't think it's that bad of an idea. The birthday paradox combined with a shitty random number generator could easily result in collisions.


Whatever the WTF of checking that a GUID generated really is unique, the method of doing so is definitely a WTF.

A GUID only really needs to be unique in its context too. If you use GUIDs in different contexts it doesn't really matter if they match. A bit like having the same primary key but for different database tables..
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment