Ross Ridge <[EMAIL PROTECTED]> wrote: > There's no SELECT in the example in the documentation as queries > aren't allowed inside of a transaction.
Ian MacLarty wrote: > There is a call to db.get. This would be analogous to a SELECT in a > relational database. I'd say the it's SELECT in GQL that's analogous to SELECT in SQL. It's the operation that determines which entities/records will get updated. > To make it work you'd either have to use a SERIALIZABLE transaction or > use an atomic update, such as: > > UPDATE counter_table SET counter = counter + 1 The example corresponds better to choosing to follow the second option. If the datastore behaved more like it was using the serializable isolation level that would imply that every datastore operation could be serialized and that a GQL SELECT operation could be performed inside of a transaction. However there's no way to guarantee the entities selected by query will still match the query conditions when read from the datastore. It's in this sense that there can be two differing "reads", the SELECT, and the actual datastore fetch. I think the basic problem here is that datastore isn't a relational database, doesn't use SQL, and so doesn't correspond perfectly with any of the ANSI standard isolation levels. Maybe the documentation shouldn't be trying to compare the datastore transaction model to any of them. Ross Ridge --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---