Changes between Version 24 and Version 25 of AppEngine
- Timestamp:
- Aug 28, 2009, 6:36:59 AM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AppEngine
v24 v25 51 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. 52 52 53 TODO: Queries should somehow support ancestor conditions.54 55 53 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. 56 54 57 Every model should provide properties for: key, key_name, key_id, parent, parent_key (all prefixed with "gae_" to reduce name conflicts) 55 TODO: Queries should somehow support ancestor conditions. 58 56 59 57 == Transactions == … … 62 60 63 61 == 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.68 62 69 63 Certain batch operations can already be emulated with the existing API: … … 87 81 }}} 88 82 83 What 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). 89 84 90 85 == Model relations and JOINs ==