Code

Changes between Version 19 and Version 20 of AppEngine


Ignore:
Timestamp:
08/12/09 02:12:21 (5 years ago)
Author:
wkornewald
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AppEngine

    v19 v20  
    3737== Keys, key_name, key id, parents == 
    3838 
    39 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'. 
     39In 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'. 
    4040 
    4141With this setup most applications should work without any modifications and automatically use key_name in a natural way. 
     
    4343Some 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). 
    4444 
    45 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. 
     45Parents are a special App Engine feature which can't be mapped transparently to Django features, so they could be simulated in two different ways: 
    4646 
    47 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. 
     47 * 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 
     48 * With a special !GAEKeyField(primary_key=True) that holds an App Engine db.Key object or its str() value. 
    4849 
    49 Queries should support ancestor conditions. 
     50Portable 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 
     52TODO: Queries should somehow support ancestor conditions. 
    5053 
    5154Every model should provide properties for: key, key_name, key_id, parent, parent_key (all prefixed with "gae_" to reduce name conflicts)