Changes between Version 19 and Version 20 of AppEngine

Timestamp:

Aug 12, 2009, 4:12:21 AM (15 years ago)

Author:

Waldemar Kornewald

Comment:

--

AppEngine

@@ -37 +37 @@
 == Keys, key_name, key id, parents ==
 
-In order to stay compatible with normal Django code the id should be emulated with an !AutoField and the key_name with a !CharField(primary_key=True). Since key_names may not start with a number the actual string is transparently prefixed with a string that can be specified in Meta.gae_key_name_prefix. The user won't notice this encoding when accessing the pk (or the !CharField). By default, this prefix is just 'k'.
+In order to stay compatible with normal Django code the id should be emulated with an !AutoField and the key_name with a !CharField(primary_key=True). Since key_names may not start with a number the actual string is transparently prefixed with a string that could be specified in Meta.gae_key_name_prefix, for example. The user won't notice this encoding when accessing the pk (or the !CharField). By default, this prefix is just 'k'.
 
 With this setup most applications should work without any modifications and automatically use key_name in a natural way.
@@ -43 +43 @@
 Some applications might mix the use of ids and key_names within the same model. For these cases you can set the prefix to an empty string. This allows for working directly with raw ids and key_names (for simplicity, the pk will always be a string, even if it's an id).
 
-Parents are a special App Engine feature which can't be mapped transparently to Django features, so they should be simulated with a separate gae_parent field that is automatically added to every model. 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.
+Parents are a special App Engine feature which can't be mapped transparently to Django features, so they could be simulated in two different ways:
 
-Code should never assume that the "pk" field is a number. If an entity uses a string pk (key_name) the application should continue to work.
+ * 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.
 
-Queries should support ancestor conditions.
+Portable code should never assume that the "pk" field is a number. If an entity uses a string pk (key_name) the application should continue to work.
+
+TODO: Queries should somehow support ancestor conditions.
 
 Every model should provide properties for: key, key_name, key_id, parent, parent_key (all prefixed with "gae_" to reduce name conflicts)