Legend:

* 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.

50

50

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.

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.

52

52

53

53

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.

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?

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.