Code

Changes between Version 4 and Version 5 of AppEngine


Ignore:
Timestamp:
02/12/09 01:34:34 (5 years ago)
Author:
wkornewald
Comment:

Elaborated on uniqueness

Legend:

Unmodified
Added
Removed
Modified
  • AppEngine

    v4 v5  
    1515A single entity (actually: a whole entity group) can't handle more than 5 writes per second (writes = save or delete). 
    1616 
    17 Unique properties can only be emulated via keys, but this means they can't be changed afterwards, so this is only useful for primary keys. 
     17Unique properties can only be emulated via the key_name, but this means their values can't be changed afterwards, so we might have to fall back to non-guaranteed uniqueness. Since you can't issue queries from within a transaction we have the problem that we can't even do a simple check in all cases. Probably we can only rely on checking on the !ModelForm level, then. Alternatively, we have to document that you can't use transactions on models that have unique properties apart from the !PrimaryKey (which can be emulated with the key_name and thus gives us a 100% uniqueness guarantee because it can be used in a transaction). 
    1818 
    1919An entity may not have more than 5000 index entries. 
     
    7979Many-to-many relations could be emulated with a !ListProperty(db.Key), so you can at least issue simple queries, but this can quickly hit the 5000 index entries limit. The alternative of having an intermediate table is useless if you have to issue queries on the data and due to the query limit you wouldn't be able to retrieve more than 1000 related entities, anyway. 
    8080 
    81 The problem with many-to-many relations is that, for example, ModelForm saves the model instance and and its many-to-many relations in separate steps. With !ListProperty this would cause multiple write operations. Also, depending on where the many-to-many relation is defined the changes could affect multiple models at once. One solution is to use batch operations as described above, but this means that all existing many-to-many code has to be optimized. Since this should be transaction-safe the field would have to be defined on a specific model, so that only one entity is affected when adding multiple relations. This means that Django has to make it easy to add new fields to existing models. 
     81The problem with many-to-many relations is that, for example, !ModelForm saves the model instance and and its many-to-many relations in separate steps. With !ListProperty this would cause multiple write operations. Also, depending on where the many-to-many relation is defined the changes could affect multiple models at once. One solution is to use batch operations as described above, but this means that all existing many-to-many code has to be optimized. Since this should be transaction-safe the field would have to be defined on a specific model, so that only one entity is affected when adding multiple relations. This means that Django has to make it easy to add new fields to existing models. 
    8282 
    8383== Special field types ==