Changes between Version 25 and Version 26 of AppEngine

Timestamp:

Aug 28, 2009, 6:41:34 AM (15 years ago)

Author:

Waldemar Kornewald

Comment:

simplified transaction spec

AppEngine

@@ -47 +47 @@
 
  * With a separate gae_parent field that is automatically added to every model or (if this isn't possible: that must be added manually). The pk itself only contains the id or key_name (without the prefix) and thus stays clean and doesn't have to be encoded in a special format. A special function allows for constructing parent paths: make_parent_path(ModelA, 23, ModelB, 'kname'). This function returns a human-readable string (e.g.: "ModelA|23|ModelB|kname") representing the path
- * With a special !GAEKeyField(primary_key=True) that holds an App Engine db.Key object or its str() value.
+ * With a special GAEKeyField(primary_key=True) that holds an App Engine db.Key object or its str() value.
 
-Some applications might mix the use of ids and key_names within the same model (does this only affect existing GAE apps?). This could be emulated cleanly with a !GAEKeyField, too. Of course, you lose portability in this case.
+Some applications might mix the use of ids and key_names within the same model (does this only affect existing GAE apps?). This could be emulated cleanly with a GAEKeyField, too. Of course, you lose portability in this case.
 
 In order to simplify porting existing applications we could also add transparent prefixing of key names (since they [http://code.google.com/p/googleappengine/issues/detail?id=1352 originally couldn't] start with a digit). This could be configurable per model, but it shouldn't be part of the actual model definition because it's only useful for old applications.
@@ -57 +57 @@
 == Transactions ==
 
-Django could emulate transactions with the commit_on_success decorator. Manual transaction handling and checkpoints can't be implemented with App Engine's current API, though. We might ask Google for help. The problem with commit_on_success is that it should run only once, but App Engine requires that it runs multiple times if an error occurs. The worst that can happen is that someone uses a custom decorator which calls commit_on_success multiple times because this could quickly hit a request limit. Maybe Django should officially change commit_on_success to issue retries?
+App Engine supports running a whole function in a transaction via db.run_in_transaction(func, args...). Manual transaction handling and checkpoints can't be implemented with App Engine's current API. We might ask Google for help.
+
+Django could emulate App Engine transactions with the commit_on_success decorator, but it doesn't really do exactly the same thing. App Engine's transactions are much more like a "SELECT FOR UPDATE" (which isn't supported by Django, yet). We might need a new transaction decorator for this.
 
 == Datastore batch operations ==