On 9/11/12 4:20 PM, Kris Borchers wrote:
I have been thinking about this a bit lately and am also hoping to
people's thoughts on whether or not this may be overkill. The reason I
say that is that really the only reason you would need such a unique id
is if there will be a chance of something else (another client, server,
etc.) generating an id for a piece of data that would conflict with this
one. What I was thinking though is that is only an issue at sync time.
As long as you know the id is unique in the client, and the status of
that piece of data (new, modified, removed), then at sync time, you can
rectify those id's that are out of sync with what is generated at the
server and you have one point of id generation.
I've always been a fan of server-side ID generation, just because I
always tend to think about malicious or badly-written clients. It's
possible for someone to pollute the ID pool such that a real ID that a
later client generates for a new object is rejected as a duplicate - and
so we'd need to account for that possibility and have the UUID
regenerated in that case. Edge case, to be sure, but those are often
where the problems lie.
That said, as long as we're careful I'm fine with client-gen'ed UUIDs.
+0 from me.