Changes between Version 9 and Version 10 of NonSqlBackends


Ignore:
Timestamp:
08/12/2009 04:28:57 AM (6 years ago)
Author:
wkornewald
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NonSqlBackends

    v9 v10  
    1616
    1717In the current implementation, multi-table inheritance requires reads and writes across multiple tables. On non-relational DBs this has to be solved differently. For example, with a ListField type you could store all models which you derived from (inspired by App Engine's PolyModel). 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).
     18
     19Problem:
     20If model B derives from A and you get an A instance and modify it you mustn't lose B's data. 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 keep them 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.
     21
     22TODO: How do we store field data that doesn't have a corresponding field in the model definition?
    1823
    1924== save_base() ==
Back to Top