[dev] What should we do about GUIDs changing?

[Marcus I. Ryan]

Sounds good, though I don't think that the servername is a good idea; what if
we change servers, change names,  or use multiple virtual servers, etc.
Better to just use the hash (though I will suggest the uniqid call I posted
earlier as it's based not just on microtime, but additional entropy as well
so should avoid the excessively rare but potential race condition.  *shrug*

Oh, and as we discussed on IRC, I must have been smoking something "special"
'cause I would have sworn until I looked back at my own dataset that we used
to use md5 hashed item ids before.  We didn't. *sigh*

--
Marcus I. Ryan, marcus at horde.org
-----------------------------------------------------------------------
  "Love is a snowmobile racing across the tundra and then suddenly it
  flips over, pinning you underneath.  At night, the ice weasels come."
                  -- Matt Groening
-----------------------------------------------------------------------


Quoting Chuck Hagenbuch <chuck at horde.org>:

> Quoting "Jason M. Felice" <jfelice at cronosys.com>:
>
>> I prefer GUIDs to sequences in databases, as 1) sequences have concurrency
>> issues which are a performance penalty under heavy load 2) sequences
>> don't work in a disconnected or remote synchronization-type scenario.
>
> Okay. I'm going to work on switching Nag, Kronolith, and Mnemo to generate
> md5-hashed unique ids instead of using sequences. I'm not going to 
> worry about
> old data, because that's just gonna be a mess; as things are, the old ids are
> at least unique from each other, so that's going to have to be good 
> enough for
> now.
>
> The @server_name would solve those, too, if necessary.
>
> -chuck
>
> --
> "Regard my poor demoralized mule!" - Juan Valdez
> --
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org