On Sunday, 31 July 2011 12:26:07 UTC+1, Stephen wrote:
>
> IDs are 64bit positive integers.


OK, that's handy to know - I haven't tried  reserving a negative range (or 
anything past 2^63) but as a python long is arbitrarily large I was guessing 
it was quite likely there'd be some such limit in the native API underneath.

If you allocate IDs for an entity called 'Sequence' you can use them
> for any other entity kind, including entities with parents which would
> otherwise use a unique range if auto allocated. IDs from 'Sequence'
> will be unique within your datastore, which is a superset of the
> requirement that IDs be unique per-entity group. However, you must
> always then use an ID from Sequence and never allow auto-allocation.
>

Really? My reading was that if I allocate a range of IDs, I can create keys 
using those IDs as well as create Keys without specifying an ID as the Key 
code will simply be doing the same (ie allocating further ranges) 
internally.

<quote>
allocate_ids(model, count)
Allocates a batch of IDs in the datastore for a datastore kind and parent 
combination.
IDs allocated in this manner will not be used by the datastore's automatic 
ID sequence generator and may be used in Keys without conflict..
</quote>

So you can safely mix auto-allocation and pre-allocation freely, but you 
shouldn't mix either auto-allocation or pre-allocation with arbitrary self 
determined allocation unless checked with allocate_id_range(). In my case, 
I've previously auto-allocated IDs for all my objects, and I'll now be 
switching to pre-allocation and explicit Key generation for selected model 
classes.

> If some of your entities have parents you can't universally 
> Kind.get_by_id().
>

I think I know what you're saying, but for anyone else reading, the point is 
that Kind.get_by_id() MUST be given both the id AND the parent that was 
specified when the Key was made (so it's easier if you're not using parents 
as you always know the parent is None). In my case, when I fetch by ID I 
will actually know the parent due to the way my datastore and queries are 
organised. But as far as I can see, if you just have the ID but not the 
parent, then there is no way to get the matching Key (but you could, for 
example, store the ID as a property on your object and then query on that if 
need be, at the cost of an extra property and index overhead).

Cheers

--
Tim

-- 
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-appengine/-/Drqp7HHhAucJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en.

Reply via email to