| 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. |
| | 126 | This is not implemented in Django-nonrel, but Vladimir Mihailenco has implemented a patch which could be integrated. |