On Tue, Aug 2, 2011 at 2:14 AM, Tim <[email protected]> wrote: > > > On Monday, 1 August 2011 11:16:40 UTC+1, Stephen wrote: >> >> Even though you're allocating from two ranges rather than one, that's >> still less than the datastore would do things automatically, so you >> still have to be careful. >> >> For example, suppose you later add an admin web interface that can >> also create new cars and add them to garages. If you let the datastore >> allocate IDs, the first car you add to any garage through this new >> code path will get ID 1 or thereabouts, because children get an ID >> from the range associated with their parent. Eventually the >> admin-generated car IDs may clash with those pre-allocated from the >> global car sequence given out to remote clients, and old data will be >> over written. >> >> So you might want to enforce that a Car model can't be created without >> passing in an ID. >> > I think I'm only now getting the subtlety of my faulty assumption. > > db.allocate_ids for a given kind does not give unique IDs for that kind, it > gives IDs that are only unique for that kind AND for a specific parent as > specified by the key used to make the call to db.allocate_ids(). >
That's correct. > So I can't pre-allocate a bunch of IDs that can be used to make keys with > whatever parent may be required without running the risk of duplicate IDs > because the ID allocation mechanism, like the Keys themselves, is actually > parent specific. > You could allocate all your IDs out of a single global pool (by specifying a fixed key to db.allocate_ids). As long as you never create an entity without specifying an ID, that will work fine - but if you do create an entity with no ID specified, there's a high probability the generated one will already exist. > This pretty much blows pre-allocated IDs out of the water for me, at least > for what I had in mind, unless I either drop entity groups altogether, or do > something like like put all items into an an entity group per user (so the > parent is something that represents the user, meaning that I know the parent > to use). Of course I could just manage my own ID allocation, but I'm never > really keen on that when a data persistance layer has its own ID/Key > mechanism. > Entity groups bear close consideration. If you don't need them for transactional integrity, don't use them. -Nick Johnson > > Oh well, back to the drawing board, thanks for the patient explanations > > -- > 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/-/fZyPanewo-AJ. > > 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. > -- Nick Johnson, Developer Programs Engineer, App Engine -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. 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.
