> On Apr 27, 1:10 am, vrypan <vry...@gmail.com> wrote:
> > I wrote some code to implement the equivalent of a "unique
> > auto_increment index" in datastore (or better, to overcome the lack of
> > it).

> > You can find the code here:
> http://vrypan.net/log/2008/04/27/unique-integer-ids-in-google-datastore/

> > It looks like it's working, but I'm a Python newbie, so please point
> > out any mistakes or performance considerations!

> I don't think that an auto-increment field is the way to go.  It is
> viable when you only have 1 database but I don't think that is how GAE
> operates.  Someone step in and correct me if I'm wrong.  The datastore
> for your app is going to/can be replicated out to other machines based
> on geographic usage.  This would mean that their exists times, when
> datastore' != datastore'' -- over time datastore' would be sync'd with
> datastore'' so that datastore' == datastore''   -- this would lead one
> to believe that there will be times when the idea of an auto-increment
> field will not be synchronizable or that the result of the
> synchronization would be less than satisfactory.  My belief that auto-
> increment fields are the wrong idea in this environment is
> strengthened by the fact that they are not offered as an intrinsic
> data type in the Model or Expando classes.

> The way to go, in my opinion, is to use UUIDs. (see links below)
>  http://docs.python.org/lib/module-uuid.html
>  http://www.faqs.org/rfcs/rfc4122.html

> 1) data access is very expensive, using a UUID should be faster
> 2) UUID1 or UUID4 would be the types to consider
> 3) UUID1 is preferable as it would introduce some machine significance
> which should make the chances for a collision to be even more remote
> than for a UUID4 (random)

> Maybe one of the Google engineers would want to comment.  Also, it
> would be nice if GAE supplied a UUID property as one of the datastore
> value types.

> -Jeff