On Dec 12, 10:06 am, Andy Freeman <ana...@earthlink.net> wrote: > > You're missing the ability to read my mind. I haven't mentioned that > (my) parent has references to (some of) its children. > > The "one put per entity in a transaction" rule means that I can't > update parent in that transaction after the child put. I can't use > parent as a parent until it has a valid key. I can't generate a
ahhh...got it. ok. in that case, you're right. using id-based keys would make your life easier, since we do the heavy lifting of generating a unique identifier (the parent key), but it would require an extra put(). we've actually recently come across the same use case internally, a couple of times. to address it, we've considered adding a "get next key" operation. you'd provide the kind and parent key, if any, and it would allocate an id you can attach to that key for use in a later put (). you'd use it to decouple id allocation and entity insertion, which is what you want to do here. the datastore reserves ids in batches, so in the common case this operation would take well under 1ms, similar to memcache. if the datastore has used up its last batch and needs to allocate a new one, that will take around 10-20ms, but that's very rare. having said that, i'm still a little skeptical that you truly need to optimize this. relative to your overall traffic pattern, i'm guessing this operation is fairly rare, so i wonder if avoiding a single extra put() is really that important. still, let us know what you think of the "get next key" operation. > Which reminds me - is the transaction for db.put([a, b,]) (for a and b > in the same entity group) run in the datastore or is it run using an > application-side transaction like good question! unlike transactions, batch puts, gets, and deletes are run in the datastore. if they hit contention, they're retried similar to transactions, except that the retries happen in the datastore, not in the application side python API. also, the work for each entity group is done in parallel, up to a point, as opposed to transactions. given that, you should generally see both asymptotic and constant factor speedups with batch writes and reads, relative to doing them individually in application code. as for quotas, those are only checked at the beginning of each call, not while the call is running in the datastore itself. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
