Changes between Version 26 and Version 27 of AppEngine
- Timestamp:
- Aug 28, 2009, 6:48:21 AM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
AppEngine
v26 v27 19 19 * setting an owner model for !ManyToManyFields (i.e., there is no intermediary table and the field's data could be stored on either the model defining the !ManyToManyField or on the other model) and !ModelForm should handle that case efficiently (i.e., try to save the relations together with the model instead of afterwards in save_m2m) 20 20 * !ListField (stores a list of values of a certain type; DB backends could use this internally for !ManyToManyFields without an intermediary table) and [http://code.djangoproject.com/ticket/2417 BinaryField] 21 * batch save() and delete() 21 * batch save() and delete() on instances 22 22 * email backends 23 23 * running Django from a zip package … … 28 28 If we emulate certain SQL features, it must be possible to detect when something gets emulated. This is important because you might mistakenly develop code that doesn't scale when your database grows beyond a certain size. In settings.py we could have a flag which specifies whether to throw warnings for emulated features (ENABLE_DB_EMULATION_WARNINGS?). By default, warnings should be enabled, so you never miss potential sources of problems. 29 29 30 Alternatively, one could have to activate emulation by calling a special function (Model.objects.with_emulation().filter(...)). That's more explicit and less error-prone.31 32 30 == Schemas == 33 31 34 Since tables are flexible and don't have schema definitions running "manage.py syncdb" shouldn't be necessary . It can still be supported by emulating a remote DB connection.32 Since tables are flexible and don't have schema definitions running "manage.py syncdb" shouldn't be necessary, but some extra functionality (like creating a superuser) which is invoked after syncdb might still be useful. 35 33 36 34 == Indexes == … … 113 111 == Email support == 114 112 115 In order to support email functionality it must be possible to provide email backends which handle the actual sending process. App Engine has a special [http://code.google.com/appengine/docs/python/mail/ Mail API]. 113 In order to support email functionality it must be possible to provide email backends which handle the actual sending process. App Engine has a special [http://code.google.com/appengine/docs/python/mail/ Mail API]. See #10355 116 114 117 115 == File uploads == … … 121 119 == Permissions and content types == 122 120 123 Since we shouldn't depend on manage.py syncdb, the Permission and !ContentType models should be replaced with dynamically generated fake model instances (which is also an optimization). Since we can retrieve the list of defined models at runtime we can easily generate those two models at runtime, too. Internally, they could be stored as a simple string (e.g., 'user.can_add') and converted into fake models when the field is accessed. This might require creating a !FakeModelField for holding this kind of model. 124 125 == Future: denormalization == 126 127 As an alternative to JOIN emulation, denormalization could be provided via a !ForeignKey that gets told which attributes of the referenced entity have to be copied. The query would then be formulated as if it crossed a relation, but internally the copied data would be used. Of course, with denormalization when an attribute changes Django must update all affected entities referencing that attribute. 128 129 Data integrity could require modifying more model instances than allowed in a single request. A background process (or cron job) could be used to automatically clean up huge amounts of data inconsistency. This would require creating a cleanup task (maybe as a model) which could at the same time be used to correct inconsistent data on-the-fly. The cache backend could optimize this process. 121 In order to prevent many inefficient JOINs the Permission and !ContentType models should be replaced with dynamically generated fake model instances. Since we can retrieve the list of defined models at runtime we can easily generate all instances for those two models at runtime, too. Internally, they could be stored as a simple string (e.g., 'user.can_add') and converted into fake models when the field is accessed. This might require creating a !FakeModelField for holding this kind of model. Alternatively, the backend itself could take care of efficiently faking those two models at a lower level (including JOIN emulation).