GUGUID

  • Mijzelf 2012-08-14 09:13
    And how big is the chance to be frist?
  • Eilert 2012-08-14 09:13
    Frist?

    This is not spam. Or is it?
  • lettucemode 2012-08-14 09:14
    Infinite loop?
  • Accalia.de.Elementia 2012-08-14 09:15
    okay.... who hacked Remy's account? there are no funny html comments!
  • Remy Porter 2012-08-14 09:19
    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*
  • toshir0 2012-08-14 09:25
    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.
  • Accalia.de.Elementia 2012-08-14 09:26
    Ah! I found the TRWTF: IE!
  • dkf 2012-08-14 09:31
    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?
  • dgvid 2012-08-14 09:32
    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.
  • YR 2012-08-14 09:49
    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!
  • Chelloveck 2012-08-14 09:50
    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.
  • Remy Porter 2012-08-14 09:54
    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.
  • toshir0 2012-08-14 09:56
    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.
  • YR 2012-08-14 09:58
    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!
  • Infinite Time and Space 2012-08-14 10:01
    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
  • Meep 2012-08-14 10:09
    Or you could, you know, use natural keys and avoid all this nonsense.

    But that would be too easy, I guess.
  • TGV 2012-08-14 10:11
    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!
  • Andrew Stein 2012-08-14 10:16
    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/
  • Remy Porter 2012-08-14 10:19
    Now that's the real WTF. That's also a reason one of the forums is the "I hate oracle club".
  • Sten 2012-08-14 10:20
    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 :-)
  • Tim 2012-08-14 10:20
    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
  • She sapped me of my precious bodily guids 2012-08-14 10:25
    GUIDs take up too much space. Use integers:

    Guid.NewGuid().ToString().GetHashCode()
  • Captcha: opto 2012-08-14 10:26
    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.
  • Shawn H Corey 2012-08-14 10:30
    You because you're not paranoid doesn't mean computers don't hate me!
  • rohcQaH 2012-08-14 10:38
    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.
  • GettinSadda 2012-08-14 10:38
    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 :-)
  • jim 2012-08-14 10:38
    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
  • spike 2012-08-14 10:53
    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!)
  • Jason 2012-08-14 10:59
    while driving your Ferrari to the diner for pancakes
    I don't eat pancakes for dinner, you insensitive clod!
  • GettinSadda 2012-08-14 11:01
    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.
  • MightyM 2012-08-14 11:05
    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)
  • GettinSadda 2012-08-14 11:06
    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.
  • That guy over there 2012-08-14 11:06
    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.
  • HERO OF THE GUID 2012-08-14 11:07
    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
  • PRMan 2012-08-14 11:12
    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.
  • Esse 2012-08-14 11:13
    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?
  • Some Jerk 2012-08-14 11:14
    He should use a dictionary to increase performance over the .Any() call.
  • QJo 2012-08-14 11:14
    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!
  • Some Jerk 2012-08-14 11:16
    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...
  • Bananas 2012-08-14 11:16
    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.
  • Recursive Reclusive 2012-08-14 11:23
    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.

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

    Lighting what?
  • Some Jerk 2012-08-14 11:32
    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.
  • Some Jerk 2012-08-14 11:39
    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...
  • She sapped me of my precious bodily guids 2012-08-14 11:57
    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()
  • Cbuttius 2012-08-14 12:10
    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.
  • Canada, eh? 2012-08-14 12:10
    Since you're driving, I would assume some kind of roadside lighting. Like a street lamp or billboard floodlight.
  • sagaciter 2012-08-14 12:10
    Slicerwizard:
    "struck by a meteor and lighting"

    Lighting what?

    If you were struck by a meteor you probably would light.
  • Cbuttius 2012-08-14 12:11
    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.
  • Cbuttius 2012-08-14 12:15
    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..
  • Coyne 2012-08-14 12:46
    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.


    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)
  • PRMan 2012-08-14 12:55
    Some Jerk:
    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...


    Believe it or don't. I don't really care. We had a duplicate that was generated. I thought it was absolutely impossible because the time/date was involved. But when I learned that they are essentially long pseudorandom numbers with a couple "version 4" codes.


    V4 GUIDs use the later algorithm, which is a pseudo-random number. These have a "4" in the same position, for example {38a52be4-9352-453e-af97-5c3b448652f0}. More specifically, the 'data3' bit pattern would be 0001xxxxxxxxxxxx in the first case, and 0100xxxxxxxxxxxx in the second. Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given full knowledge of the internal state, it is possible to predict previous and subsequent values.[4]


    Let me ask you this: Do you really think that Microsoft's pseudorandom generator algorithm is so good that it could never give a duplicate?

    I mean, there's a reason that Google gives 624,000 results when searching for "Duplicate GUID". They can't all have done it wrong...
  • Some Jerk 2012-08-14 12:59
    Coyne:
    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.


    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)


    I find it remarkable how much support that mindset is gaining as technology improves. Truthfully, I despise the strategy. For example... Entity Framework generating 200 lines of code for every 1 line that actually needs to be there.

    I can host 10 web apps on my workstation while playing City of Heroes and downloading animes at 2MB/sec without suffering slow response times. Yes... my system definately has the hardware for it... but it would not work if I was silly enough to think (just do whatever and add hardware if it needs it).
  • Harrow 2012-08-14 12:59
    GettinSadda:
    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.
    Any halfway competent security analyst can tell you that a security scheme that depends on my MAC address remaining secret is doomed. For starters, if my MAC address is compromised I cannot change it.

    This is typical Microsoft crap on a stick. The only thing that distinguishes UuidCreate from a bog standard PRNG is the the temporal and spatial components -- so let's break them.

    When I first saw UuidCreate I didn't trust it. Not because I think it can't work, not because UUIDs are long and ugly, not because there are better methods, but because it's implemented by Microsoft.

    The value of a UUID scheme is the mathematical rigor of its specification. At Microsoft, a developer who admits he can even spell "mathematical rigor" goes immediately to the bottom of the stack.

    -Harrow.
  • neminem 2012-08-14 13:00
    Cbuttius:
    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.

    Hey, I actually (sort of) got one; I asked a question and the answer got blue'd up.

    This is even kinda relevant to this article, as the question asked was "can I still steal^Hacquire a t-shirt even if I have no desire, nor in fact any particular ability to test out New Relic's software on any real applications?", and the official answer here seemed to be "yes", so I did. Interestingly enough, <i>New Relic</i>'s official answer, according to their faq, would seem to be "no", but I wanted a t-shirt, so I did it anyway. Presumably New Relic wasn't actually reading the comments on their advertisement's thread. :p
  • Some Jerk 2012-08-14 13:02
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.

    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
  • Larry 2012-08-14 13:26
    GettinSadda:
    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.
    Kids throwing around cosmology stuff as if they know what they're talking about are TRWTF.

    First of all, an awful lot of events happened in the first second after the BB. Hell, forget the first second, let's just focus on the first thousandth of a second...

    Anyway, the point is, the Universe was so small that with the speed of light and all that you could get a hell of a lot done in a very short time. In other words, it was as if time proceeded a lot slower than it does now.

    Which means most of those GUIDs would have been calculated before the formation of the first atoms.
  • ORly? 2012-08-14 13:29
    spike:
    TRWTF is that this code was written in the first place, it stinks of premature protection.
    Premature protection? Is that what you call it now? Is that your lofty-sounding excuse for not testing anything until it breaks in production?
  • Andrew Stein 2012-08-14 13:38
    250k duplicate GUIDs in a set of 3 million, we sure need this DiffeerentGuid method..
  • Some Jerk 2012-08-14 13:45
    Andrew Stein:
    250k duplicate GUIDs in a set of 3 million, we sure need this DiffeerentGuid method..


    one problem is that the guid generator still depends on random numbers, which are generated by system clock. based on your count, 1 of 6 guids were duplicated. Thread.sleep for 100ms and try it again. I suspect that 10 MS would do it... but just to be sure.
  • n_slash_a 2012-08-14 13:53
    QJo:
    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!

    Open IE (because anyone that "smart" uses IE) to your company's home page and press F5 as fast as possible to signal your developers to return.
  • Andrew Stein 2012-08-14 14:08
    Hi Some Jerk :-)

    My comments were in reference to the generation of GUIDs in parallel in Oracle. See http://sqlfascination.com/2012/01/22/oracle-duplicate-guid-values-being-returned-from-sys_guid-when-run-in-parallel/

    Sleeping would defeat the purpose.
  • Andrew Stein 2012-08-14 14:09
    Some Jerk:
    Andrew Stein:
    250k duplicate GUIDs in a set of 3 million, we sure need this DiffeerentGuid method..


    one problem is that the guid generator still depends on random numbers, which are generated by system clock. based on your count, 1 of 6 guids were duplicated. Thread.sleep for 100ms and try it again. I suspect that 10 MS would do it... but just to be sure.


    Hi Some Jerk :-)

    My comments were in reference to the generation of GUIDs in parallel in Oracle. See http://sqlfascination.com/2012/01/22/oracle-duplicate-guid-values-being-returned-from-sys_guid-when-run-in-parallel/

    Sleeping would defeat the purpose.
  • Barf 4eva 2012-08-14 14:17
    When Guid isn't Guid enough, use DifferentGuid.
  • Some Jerk 2012-08-14 14:19
    Ahh. I am surprised that Oracle has that problem. I made a blanket comment earlier that ORDBMS servers would be an ideal place to maintain uniqueness among such fields, as it is inherrent in the architecture to deny duplicates (with constraints). It seems that this might be more challenging for Oracle to handle than MS Sql Server. Can you force the insert to retry if it fails? Just curious.
  • Some Jerk 2012-08-14 14:29
    Some Jerk:
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.

    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
    Afraid of having your good name besmirched, matterhorn?
  • Some Jerk 2012-08-14 14:32
    Larry:
    GettinSadda:
    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.
    Kids throwing around cosmology stuff as if they know what they're talking about are TRWTF.

    First of all, an awful lot of events happened in the first second after the BB. Hell, forget the first second, let's just focus on the first thousandth of a second...

    Anyway, the point is, the Universe was so small that with the speed of light and all that you could get a hell of a lot done in a very short time. In other words, it was as if time proceeded a lot slower than it does now.

    Which means most of those GUIDs would have been calculated before the formation of the first atoms.
    Who are you trying to fool? I'm no Einstein, but isn't time constant?
  • Some Jerk 2012-08-14 14:32
    Some Jerk:
    Some Jerk:
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.

    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
    Afraid of having your good name besmirched, matterhorn?


    Not really... it was just a subtle suggestion that certain people could maybe produce their own ideas as opposed to using those of others durring the name selection process. I attempted to word it as politely as possible.
  • Some Jerk 2012-08-14 14:36
    Some Jerk <-- Imposter:

    Who are you trying to fool? I'm no Einstein, but isn't time constant?


    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.
  • Some Jerk 2012-08-14 15:03
    Some Jerk:
    Some Jerk <-- Imposter:

    Who are you trying to fool? I'm no Einstein, but isn't time constant?


    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.
    The fact that you think anyone else cares speaks volumes on your intelligence.
  • PedanticCurmudgeon 2012-08-14 15:17
    Some Jerk:
    Some Jerk:
    Some Jerk <-- Imposter:

    Who are you trying to fool? I'm no Einstein, but isn't time constant?


    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.
    The fact that you think anyone else cares speaks volumes on your intelligence.
    Does anyone else have a weird sense of deja vu here?
  • Some Jerk 2012-08-14 15:21
    :p

    see? Someone does care. Now grow an imagination... or failing that, feel free to post as "Some Jerk is a dickhead" or something... if you suddenly found that the most interesting thing to do with your life is to harrass me on a message board.

    Anyway... I never said that I thought "SOMEONE" cared... only said that "I" cared.
  • Zylon 2012-08-14 15:30
    Harrow:
    For starters, if my MAC address is compromised I cannot change it.

    Ahem.
  • Recursive Reclusive 2012-08-14 15:58
    Some Jerk:
    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?

    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...

    You say that as if it in any way contradicts what I wrote.
  • frits 2012-08-14 16:11
    PedanticCurmudgeon:
    Some Jerk:
    Some Jerk:
    Some Jerk <-- Imposter:

    Who are you trying to fool? I'm no Einstein, but isn't time constant?


    Though I must admit... using my handle exclusively to spout nonsense really is unkind. I suspect (however) that most can tell the difference. You should try to be more subtle... and actually say something intelligent once in a while... and it might pass for me.
    The fact that you think anyone else cares speaks volumes on your intelligence.
    Does anyone else have a weird sense of deja vu here?
    Yep.
  • The Joker 2012-08-14 16:46
    You shouldn't leave these things to chance.
  • pbean 2012-08-14 16:47
    What are the "fancy html comments" I keep reading about? I don't think I've ever seen them. :S And I read the first page of comments on nearly every article.
  • David F. Skoll 2012-08-14 17:00
    I wonder what the test coverage of the body of the
    while
    loop is like?
  • David F. Skoll 2012-08-14 17:02
    Ah, but if you get a bigger server, you hasten the heat death of the universe, so you are defeated once again!
  • I dunno if I should reply but I'll do it anyways. 2012-08-14 17:17
    Some Jerk:
    I'm no Einstein, but isn't time constant?
    No, you're definitely no Einstein.
  • Raphael 2012-08-14 17:30
    Harrow:
    Any halfway competent security analyst can tell you that a security scheme that depends on my MAC address remaining secret is doomed. For starters, if my MAC address is compromised I cannot change it.

    This is typical Microsoft crap on a stick. The only thing that distinguishes UuidCreate from a bog standard PRNG is the the temporal and spatial components -- so let's break them.

    When I first saw UuidCreate I didn't trust it. Not because I think it can't work, not because UUIDs are long and ugly, not because there are better methods, but because it's implemented by Microsoft.

    The value of a UUID scheme is the mathematical rigor of its specification. At Microsoft, a developer who admits he can even spell "mathematical rigor" goes immediately to the bottom of the stack.

    -Harrow.
    Who uses UUIDs for security purposes? Aren't they just for differentiating two things? Like COM interfaces, or partitions.
  • Hi No Einstein, I'm Tom 2012-08-14 17:41
    Some Jerk:
    I'm no Einstein, but isn't time constant?
    Time is a function of the speed of light, so as light slows down due to the expansion of the Universe, time does too, so that we perceive the speed of light as a constant.
  • Evoex 2012-08-14 17:42
    PRMan:

    I mean, there's a reason that Google gives 624,000 results when searching for "Duplicate GUID". They can't all have done it wrong...


    There's a reason that Google gives 12,600,000 results when searching for "void main". It can't be wrong then, right?
  • Coyne 2012-08-14 18:46
    Evoex:
    PRMan:

    I mean, there's a reason that Google gives 624,000 results when searching for "Duplicate GUID". They can't all have done it wrong...


    There's a reason that Google gives 12,600,000 results when searching for "void main". It can't be wrong then, right?


    Let's get this straight: He counted "velociraptors that are running loose" and you counted "all occurrences of 'WTF' on the web"...and you're using your count as an explanation for why his count doesn't indicate any concern?

    All I can say is: +1
  • Coyne 2012-08-14 19:04
    Raphael:
    Harrow:
    The value of a UUID scheme is the mathematical rigor of its specification. At Microsoft, a developer who admits he can even spell "mathematical rigor" goes immediately to the bottom of the stack.

    -Harrow.
    Who uses UUIDs for security purposes? Aren't they just for differentiating two things? Like COM interfaces, or partitions.


    Even if GUIDs aren't used for security themselves, they reveal details about their origin that might be considered secure.

    Ignoring the fact that wireless is often sensitive to MAC for example, think about assigning a GUID to an election ballot: The GUID reveals the election machine and the time of creation, which means that the individual that cast the ballot can be identified--a violation of secret ballot.

    Of course, UUID is probably equally unusable, really, since I suspect MS carefully buried all that information in the ID anyway. Like NSA, they can't stand it if they don't know exactly where and when the UUID was created, so they probably just used some kind of lame hardcoded encryption to hide the details. I won't be surprised if we hear about someone breaking the UUID protection scheme at some point, so that MAC and time can be extracted.
  • Luiz Felipe 2012-08-14 21:22
    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.


    Perhaps the guid generator dont generate new guids every time, perhaps it increments stored generated guid and time from time update. Then you have a multthreaded program, th collision can happen once or twice a month.
  • Luiz Felipe 2012-08-14 21:24
    Sten:
    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 :-)

    But what if in multiverse we have duplicated values, this can be a serous problem for multi-space-time research lab.
  • Michelle 2012-08-14 21:32
    article:

    Sure, you're more likely to be struck by a meteor and lighting while winning the lottery on the last Tuesday before Lent while driving your Ferrari to the diner for pancakes, but it can happen!

    FTFY
  • fheiwo 2012-08-14 22:40
    Coyne:
    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.


    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)
    Big Blue? I guess it could be any of the others too....
  • Jugiga 2012-08-14 22:47
    n_slash_a:
    QJo:
    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!

    Open IE (because anyone that "smart" uses IE) to your company's home page and press F5 as fast as possible to signal your developers to return.
    What's Open IE? Firefox?

    Captcha: combover
  • I wanna go too 2012-08-14 22:48
    Some Jerk:
    Some Jerk:
    Some Jerk:
    Some Jerk <- imposter:
    He should use a dictionary to increase performance over the .Any() call.

    hmmm. I didn't see anyone else posting as me when I was unregistered. Glad that I registered... I would hate for anybody to think this came from me.
    Afraid of having your good name besmirched, matterhorn?


    Not really... it was just a subtle suggestion that certain people could maybe produce their own ideas as opposed to using those of others durring the name selection process. I attempted to word it as politely as possible.
    But he's "Some Jerk (unregistered)" which appears totally different to "Some Jerk"
  • Hulio 2012-08-14 22:50
    pbean:
    What are the "fancy html comments" I keep reading about? I don't think I've ever seen them. :S And I read the first page of comments on nearly every article.
    Brillant!
  • Evoex 2012-08-14 22:53
    Some Jerk:
    Larry:
    GettinSadda:
    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.
    Kids throwing around cosmology stuff as if they know what they're talking about are TRWTF.

    First of all, an awful lot of events happened in the first second after the BB. Hell, forget the first second, let's just focus on the first thousandth of a second...

    Anyway, the point is, the Universe was so small that with the speed of light and all that you could get a hell of a lot done in a very short time. In other words, it was as if time proceeded a lot slower than it does now.

    Which means most of those GUIDs would have been calculated before the formation of the first atoms.
    Who are you trying to fool? I'm no Einstein, but isn't time constant?


    That comment, my friend, deserves a very high position in the thedailywtf hall of shame.
  • marc 2012-08-14 23:14

    more likely to be struck by a meteor and lighting while winning the lottery on a Tuesday during Lent while driving your Ferrari to the diner for pancakes


    This statement suggests that all events must happen around the same time. Let's loosen the simultaneity requirement to be that all these events happen during the same hour, to be very fair.

    The probability of being hit by lightning is about 1e-6 per year or 1e-10 per hour.

    Let's assume that one person in the US gets hit by by a meteor every year, which internet searches suggest to be a high estimate. Then the probability of being hit by a meteor is about 1e-8 per year or 1e-12 per hour.

    If you play a typical lottery once a day, you have about 1e-8 probability of winning per day or about 1e-9 per hour.

    There are less than 10 Tuesdays during Lent, giving less than 1e-1 probability that any given day is a Tuesday during Lent.

    Ferrari makes about 1e4 Ferraris per year, so there are less than 1e6 Ferraris in the US. Therefore the probability that a random person in the US owns a Ferrari is less than 1e-2.

    Finally, let's say you spend 15 minutes every driving to a diner for pancakes. This gives 1e-2 probability that you are driving to a diner for pancakes.

    Multiplying everything together, we get 1e-36 probability per hour. Given the roughness of the estimate, that's very close to the 1e-37 probability of collision of two completely random GUIDs. So don't be so confident.

    (Of course, a better estimate would also have to account for the fact that people have more than one hour in their lives in which to have this unfortunate accident. But a better estimate would also have to account for the fact that there are usually more than two GUIDs to collide. And because of the birthday paradox, I don't expect these additional details would weigh in favor of the article's statement.)
  • Coyne 2012-08-15 00:46
    fheiwo:
    Coyne:
    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.


    So? Performance is a hardware problem. Just get a bigger server (these days: buy more cloud) and everything will be well.

    (At least, that's how our vendors solve performance problems.)
    Big Blue? I guess it could be any of the others too....


    It's mostly other vendors. "Tuning" is a dead art, I guess.
  • Gruntled 2012-08-15 01:19
    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


    It makes sense to write your code in a way that it gracefully handles a duplicate, just in case a software bug generates one and you don't want to lose data or order $100 million worth of the wrong stuff. Writing clock cycle munching code to prevent duplicates from forming defeats the purpose of using UUIDs and you might as well use a counter in a central repository. Even with locking, it's likely going to be faster than searching your entire backlog of generated ID's for duplicates like this code does...
  • Huh? 2012-08-15 01:30
    marc:

    more likely to be struck by a meteor and lighting while winning the lottery on a Tuesday during Lent while driving your Ferrari to the diner for pancakes


    This statement suggests that all events must happen around the same time. Let's loosen the simultaneity requirement to be that all these events happen during the same hour, to be very fair.

    The probability of being hit by lightning is about 1e-6 per year or 1e-10 per hour.

    Let's assume that one person in the US gets hit by by a meteor every year, which internet searches suggest to be a high estimate. Then the probability of being hit by a meteor is about 1e-8 per year or 1e-12 per hour.

    If you play a typical lottery once a day, you have about 1e-8 probability of winning per day or about 1e-9 per hour.

    There are less than 10 Tuesdays during Lent, giving less than 1e-1 probability that any given day is a Tuesday during Lent.

    Ferrari makes about 1e4 Ferraris per year, so there are less than 1e6 Ferraris in the US. Therefore the probability that a random person in the US owns a Ferrari is less than 1e-2.

    Finally, let's say you spend 15 minutes every driving to a diner for pancakes. This gives 1e-2 probability that you are driving to a diner for pancakes.

    Multiplying everything together, we get 1e-36 probability per hour. Given the roughness of the estimate, that's very close to the 1e-37 probability of collision of two completely random GUIDs. So don't be so confident.

    (Of course, a better estimate would also have to account for the fact that people have more than one hour in their lives in which to have this unfortunate accident. But a better estimate would also have to account for the fact that there are usually more than two GUIDs to collide. And because of the birthday paradox, I don't expect these additional details would weigh in favor of the article's statement.)
    But there are more people in the world than just in the US...even if only US people get hit by meteorites, we have to take into account EVERYONE
  • Norman Diamond 2012-08-15 02:50
    Out of curiosity, are UUIDs more unique than GUIDs? Yes!

    Inside curiosity, are UUIDs more unique than GUIDs? No!

    Because even if a GUID inside curiosity is duplicated by others, only the one inside curiosity is local to Mars.
  • Cbuttius 2012-08-15 05:16
    The difference between a GUID and a UUID is that the same GUID can exist somewhere on another planet while a UUID cannot, it is universally unique.

    For spaceships therefore, you need UUIDs just to be safe.
  • Cbuttius 2012-08-15 05:17
    Evoex:

    There's a reason that Google gives 12,600,000 results when searching for "void main". It can't be wrong then, right?


    "void main" is correct in C# and Java, incorrect in C and C++.
  • Wody 2012-08-15 05:42
    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.


    it's going to run out on the 21st of december this year. Will something happen? Maybe, maybe not. Who knows?
  • ThomasX 2012-08-15 06:05
    Lets analyze the function. If we find a unique GUID at the first try we have the best case of O(1).

    But what about the worst case? What if the same GUID is generated 10 million times in a row? What if the same GUID is generated 10 billion times in a row? What if the same GUID is generated 10 trillion times in a row? What if the same GUID is generated 10 quadrillion times in a row? What if the same GUID is generated 10 quintillion times in a row? What if the same GUID is generated 10 sextillion times in a row? What if the same GUID is generated 10 septillion times in a row? What if the same GUID is generated 10 octillion times in a row? What if the same GUID is generated 10 nonillion times in a row? What if the same GUID is generated 10 decillion times in a row? What if the same GUID is generated 10 undecillion times in a row? What if the same GUID is generated 10 duodecillion times in a row?

    We see the worst case is actually O(infinity). That gives a complexity of O(infinity/2) in the average case which is clearly inacceptable. To be on the safe side we need the possibility to pass a timeout to the function.
  • Hegel 2012-08-15 06:18
    The method should be refactored to

    private Guid DifferentGuid(params Guid[] guids, IGuidGenerator generator)


    just in case the built-in GUID generator implementation does not generate unique-enough GUIDs.
  • Lockwood 2012-08-15 06:44
    Remy Porter:
    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*

    And why no unicorns?!
  • Harrow 2012-08-15 11:04
    Zylon:
    Harrow:
    For starters, if my MAC address is compromised I cannot change it.

    Ahem.
    Good point. But what are the PHB's at MS worried about exposing, the spoofed MAC or the hardware MAC on the NIC?

    -Harrow.
  • consequat 2012-08-15 11:38
    Andrew Stein:
    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/


    That's why smart people run away from crappy systems like Oracle and Java and similar undocumented crap like Unix.
  • consequat 2012-08-15 11:42
    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)


    I know - a day won't pass that I don't stumble upon a dumbass.
  • Maurits 2012-08-15 11:45
    TRWTF is that this function could loop infinitely.

    An obviously-better implementation would be to apply a Cantor diagonalization scheme to the given list of GUIDs.
  • jay 2012-08-15 13:24
    ORly?:
    spike:
    TRWTF is that this code was written in the first place, it stinks of premature protection.
    Premature protection? Is that what you call it now? Is that your lofty-sounding excuse for not testing anything until it breaks in production?


    "Premature protection" ... like buying an umbrella on a day when it isn't raining; or getting life insurance even though you have, so far, never died.
  • Some Jerk 2012-08-15 17:25
    jay:
    ORly?:
    spike:
    TRWTF is that this code was written in the first place, it stinks of premature protection.
    Premature protection? Is that what you call it now? Is that your lofty-sounding excuse for not testing anything until it breaks in production?


    "Premature protection" ... like buying an umbrella on a day when it isn't raining; or getting life insurance even though you have, so far, never died.


    Or wearing a rubber with the rest of your daily attire in the event that it might be useful for once.
  • Luc 2012-08-16 04:06
    While (comments.Next)
    If Comment.equals ('Frist')
    DifferentComment('Secunt')
  • oheso 2012-08-16 07:33
    Cbuttius:
    A bit like having the same primary key but for different database tables..


    Man, you have that problem too? How do you take care of it?
  • oheso 2012-08-16 07:39
    Some Jerk:
    Can you force the insert to retry if it fails?


    Thankfully, this is illegal in enlightened states.
  • Neil 2012-08-17 05:39
    Some Jerk (unregistered):
    I'm no Einstein, but isn't time constant?
    Time is an illusion. Lunchtime doubly so.

    Captcha: mara

    This is only significant because it's the first time that my captcha was already present in my browser's autocomplete. So you could say I had a collision. Maybe we need to start using GUIDs for captchas?
  • Kuba 2012-08-17 14:05
    All the suggestions as to how to do it "safer" presented above are silly. It's obvious how it should be done.

    1. Register a domain, call it "tehguids.net"

    2. Every enterprise that generates guids gets their own server on a subdomain there, serving a linked page of guids it generated since its inception.

    3. Everytime a suggested guid is to be passed from the API to the caller, a google search is done with site:tehguids.net to ensure no such GUID was issued beforehand.

    Simple, scalable, leverages teh cloud, and in case of offline generation you use whatever OS api/library is there for the guid generation, but you double-check things when you get back online, and if there are collisions, the fix is only a quick sql UPDATE query away.
  • Martin 2012-08-17 16:10
    Actually we ran into a situation where we had many (~2%) GUID-Collisions! It was a mobile system without a MAC-Address and only a default time on boot-up...
  • Lelala 2012-08-21 08:05
    LOL, thats really a cool WTF :-)
    But why didn't that guy use just a simple HashOf( OneGUID + AnotherGUID + AndAThirdGUIDIfHeWants ) ?
    Regards,
    Lelala
    http://www.lelala.de
  • Typhin 2012-09-05 18:35
    I don't know if this is mentioned, but depending on how the "Any" method works, there could be a subtle bug in this code. (I don't know which language this is, so I can't look it up, and "Any" is such a vague term to Google.)

    Does Any() recheck the guids it checked before, when result gets a new guid? If not, it could end up colliding with a previously-checked guid after colliding with one later in the array. In which case, I want that guy's lottery tickets.
  • TortoiseWrath 2012-10-16 21:26
    Well, in a given year, one's chance of being struck by a meteorite is 1 in 1.7*10^10; as such, one's chance of being struck by a meteorite during a one-hour period on any Tuesday during Lent (43 days) is about 1 in 2.1*10^13, or 1 in 1.5*10^14 on any given one of these days.

    The chance of winning the Lotto jackpot on a given night with random numbers is about 1 in 1.4*10^7. By multiplying this by 1 in 1.5*10^14, we find that the probability of being struck by a meteor and winning the lottery on a given Tuesday is 1 in 2.1*10^21; doing this on one of six days, the odds are 1 in 3.5*10^20.

    Though the other things are personal choices, I'll factor them in anyway:

    ~7,000 Ferraris were produced in 2011; if we extrapolate this over 65 years of Ferraris existing, there are about 455,000 Ferraris, meaning that there is about a 1 in 15,385 chance that a particular person owns one.

    I couldn't find any pancake-related statistics, but IHOP served about $50M of pancakes to Americans in 2006, so the probability of a particular American eating pancakes on a given day is about 1 in 2192.

    If we multiply all of this together, we find that the odds of doing all that are about 1 in 1.2*10^28. This is still a significantly better chance than the 1 in 1.1*10^37 chance of two GUIDs colliding.