Changes between Version 25 and Version 26 of AppEngine


Ignore:
Timestamp:
08/28/2009 06:41:34 AM (6 years ago)
Author:
wkornewald
Comment:

simplified transaction spec

Legend:

Unmodified
Added
Removed
Modified
  • AppEngine

    v25 v26  
    4747
    4848 * 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
    49  * With a special !GAEKeyField(primary_key=True) that holds an App Engine db.Key object or its str() value.
     49 * With a special GAEKeyField(primary_key=True) that holds an App Engine db.Key object or its str() value.
    5050
    51 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.
     51Some 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.
    5252
    5353In 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.
     
    5757== Transactions ==
    5858
    59 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?
     59App 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.
     60
     61Django 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.
    6062
    6163== Datastore batch operations ==
Back to Top