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
-~----------~----~----~----~------~----~------~--~---
