Changes between Version 4 and Version 5 of AppEngine

Timestamp:

Feb 12, 2009, 3:34:34 AM (15 years ago)

Author:

Waldemar Kornewald

Comment:

Elaborated on uniqueness

AppEngine

@@ -15 +15 @@
 A single entity (actually: a whole entity group) can't handle more than 5 writes per second (writes = save or delete).
 
-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.
+Unique 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).
 
 An entity may not have more than 5000 index entries.
@@ -79 +79 @@
 Many-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.
 
-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.
+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.
 
 == Special field types ==