Context Navigation

Changes between Version 9 and Version 10 of NonSqlBackends

-              v9
+              v10
 In 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).
+Problem:
+If 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.
+TODO: How do we store field data that doesn't have a corresponding field in the model definition?
 == save_base() ==