Changes between Version 23 and Version 24 of AppEngine
- Timestamp:
- Aug 28, 2009, 6:31:29 AM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AppEngine
v23 v24 42 42 == Keys, key_name, key id, parents == 43 43 44 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'. 45 46 With this setup most applications should work without any modifications and automatically use key_name in a natural way. 47 48 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). 44 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). 49 45 50 46 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: … … 53 49 * With a special !GAEKeyField(primary_key=True) that holds an App Engine db.Key object or its str() value. 54 50 55 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.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. 56 52 57 53 TODO: Queries should somehow support ancestor conditions. 54 55 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. 58 56 59 57 Every model should provide properties for: key, key_name, key_id, parent, parent_key (all prefixed with "gae_" to reduce name conflicts)