Code

Changes between Version 26 and Version 27 of AppEngine


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

--

Legend:

Unmodified
Added
Removed
Modified
  • AppEngine

    v26 v27  
    1919 * 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) 
    2020 * !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 
    2222 * email backends 
    2323 * running Django from a zip package 
     
    2828If 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. 
    2929 
    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  
    3230== Schemas == 
    3331 
    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. 
     32Since 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. 
    3533 
    3634== Indexes == 
     
    113111== Email support == 
    114112 
    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]. 
     113In 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 
    116114 
    117115== File uploads == 
     
    121119== Permissions and content types == 
    122120 
    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. 
     121In 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).