> A two-stage insertion would work fine, then. Insert the first object > with a "not-ready" flag set, insert the second object, then go back > and flip the "not-ready" flag.
If the application has a datastore or quota timeout between the "store to get a key" and the store for the actual data, the "store to get a key" results in an incomplete group. Note that the "not ready flag" adds a third store and another opportunity for an incomplete group (namely a complete group that is marked not-ready). These are precisely the sorts of problems that transactions solve. > Generating an application-globally-unique name is hard. No, it's not hard at all. The MAC address, time, and process id suffice (for single threaded applications like GAE, otherwise the thread id is also needed) and there are other info combos that can be used to generate such names. Moreover, there are plenty of methods that can be used to generate a unique name from such information that don't expose the underlying data. (Google may well want to make it impossible to determine MAC addresses or process ids, for example.) It's only hard within the current GAE API because that API doesn't expose enough information or provide a method that generates a unique name without exposing the information used to generate said name. > Who said the datastore would be on the same machine as the running > application, anyway? Huh? Nothing that I've written said anything about the machines where the datastore is running. That information isn't necessary for an application to generate a unique name. Asking that question suggests that you don't understand what I've been talking about. On Nov 22, 9:16 pm, "David Symonds" <[EMAIL PROTECTED]> wrote: > On Sun, Nov 23, 2008 at 1:38 PM, Andy Freeman <[EMAIL PROTECTED]> wrote: > >> Yes, I understand transactions and entity groups. Why do you need to > >> create an entity group *atomically*? > > > For the same reason that transactions are useful - incomplete groups > > are wrong (in my application) and I'd rather not deal with them. > > > >> If you create a new entity, it will automatically be assigned a unique > >> key at the datastore level. What's wrong with just using that? > > > Each db.put has significant overhead. If I can generate a unique name > > without a db.put, I can reduce the number of db.puts that my > > application does by a factor of 2. > > Generating an application-globally-unique name is hard, and App Engine > is mainly focused on applications where the writes are few and the > reads are many. Until you've benchmarked it, it sounds like you are > prematurely optimising for an operation that should be relatively > rare, while seriously increasing the complexity of your system. Who > said the datastore would be on the same machine as the running > application, anyway? > > Dave. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
