Code

Changes between Version 23 and Version 24 of AppEngine


Ignore:
Timestamp:
08/28/09 04:31:29 (5 years ago)
Author:
wkornewald
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AppEngine

    v23 v24  
    4242== Keys, key_name, key id, parents == 
    4343 
    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). 
     44In 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). 
    4945 
    5046Parents are a special App Engine feature which can't be mapped transparently to Django features, so they could be simulated in two different ways: 
     
    5349 * With a special !GAEKeyField(primary_key=True) that holds an App Engine db.Key object or its str() value. 
    5450 
    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. 
     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. 
    5652 
    5753TODO: Queries should somehow support ancestor conditions. 
     54 
     55In 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. 
    5856 
    5957Every model should provide properties for: key, key_name, key_id, parent, parent_key (all prefixed with "gae_" to reduce name conflicts)