Code

Changes between Version 24 and Version 25 of AppEngine


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

--

Legend:

Unmodified
Added
Removed
Modified
  • AppEngine

    v24 v25  
    5151Some 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. 
    5252 
    53 TODO: Queries should somehow support ancestor conditions. 
    54  
    5553In 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. 
    5654 
    57 Every model should provide properties for: key, key_name, key_id, parent, parent_key (all prefixed with "gae_" to reduce name conflicts) 
     55TODO: Queries should somehow support ancestor conditions. 
    5856 
    5957== Transactions == 
     
    6260 
    6361== Datastore batch operations == 
    64  
    65 Datastore writes are very expensive. App Engine provides batch operations for saving and deleting lots of model instances at once (no more than 500 entries, though). Django should provide such an API, too, so code can be optimized. Note that while Django does support a few batch operations they work at the DB level, so the model instances' save() and delete() methods are never called. 
    66  
    67 The API would be most flexible if it worked like a transaction handler where all save() calls within a function call are collected and then committed afterwards. The implementation wouldn't be trivial, though. It requires maintaining a cache of to-be-saved instances, so filter() calls can check the cache. Also, when a real transaction starts the cache must be flushed and disabled because in transactions we have to interact with the DB directly in order to lock an entity group. Instead of a decorator we could also provide a middleware, but this could lead to problems if, for instance, the view issues an http request (e.g., to start a task) and thus requires that the data has already been stored. 
    6862 
    6963Certain batch operations can already be emulated with the existing API: 
     
    8781}}} 
    8882 
     83What we also need is a way to batch-create/update model instances. Also, batch-deletes should work with model instances and reuse the model instances when sending signals (currently, they're re-fetched which is inefficient). 
    8984 
    9085== Model relations and JOINs ==