Changes between Version 14 and Version 15 of NoSqlSupport


Ignore:
Timestamp:
04/27/2011 03:02:52 AM (4 years ago)
Author:
wkornewald
Comment:

removed multi-table inheritance explanation (none of the solutions is good enough, so let's just not support it)

Legend:

Unmodified
Added
Removed
Modified
  • NoSqlSupport

    v14 v15  
    124124For optimization purposes it's very important to allow batch-saving and batch-deleting a list of model instances (which, in the case of batch-deletion, is not exactly the same as `QuerySet.delete()` which first has to fetch the entities from the DB in order to delete them).
    125125
    126 This is not implemented in Django-nonrel, but Vladimir Mihailenco has implemented a patch which can be easily reused at least by NoSQL backends.
    127 
    128 = Multi-table inheritance =
    129 
    130 Multi-table inheritance requires JOIN support, so this feature can't be fully supported.
    131 
    132 On non-relational DBs it could be partially emulated with a `ListField` that stores all model names which it derives from. E.g., if model B derives from model A it would store model B in model A's table and add B's name (app_b) to the `ListField`.
    133 
    134 On App Engine this adds deeper composite indexes which is a problem when filtering against multiple `ListFields` combining that with inequality filters or results ordering (exploding indexes). Thus, this should only be used at the second inheritance level (seen from Model base class).
    135 
    136 Problem:
    137 Model A doesn't know about model B, but since both of them live in the same table an A instance has to know about B's fields, so when A is saved it can preserve B's data (you can't modify only specific fields; you always replace the whole row). Either we always keep all data (which means you never free up data after schema changes unless you use a lower-level API) or we keep track of all derived models' fields and preserve those while removing all unused fields (e.g., A would know about B's fields and preserve them when saving). Probably the first solution is the safest.
    138 
    139 This is not implemented in Django-nonrel.
     126This is not implemented in Django-nonrel, but Vladimir Mihailenco has implemented a patch which could be integrated.
    140127
    141128= Transactions =
     
    152139
    153140Django-nonrel doesn't yet support bookmarks, but the App Engine backend provides a private API for them.
     141
     142
     143= Multi-table inheritance =
     144
     145Multi-table inheritance requires JOIN support, so this feature can't be fully supported. For convenience it would be nice to allow subclassing a non-abstract model, but only copying its fields as if it were abstract.
Back to Top