Legend:

''There are some broken assumptions here. Multi-table inheritance is, by definition, just syntactic sugar for one-to-one relations to other tables. This proposal suggests effectively converting multi-table inheritance to single-table inheritance, which breaks the only reason it exists: (a) a single table to query for common parent information and (b) the ability to extend third-party models without modification, whilst still updating the third-party tables. But only on app-engine, leading to different behaviour there than on relational storage systems, meaning nobody can make reasonable assumptions about how their app would run if they are required to have it work in a storage-agnostic fashion. We should fail properly for unsupported features, not have behavioural breakage by appearing to run, but not work the same. If a third-party storage engine cannot support linked tables by any kind of fakery, then apps using multi-table inheritance just can't run on those storage engines. Django shouldn't be crippled to support the lack of relational support in such storage engines. It's called an O*R*M, after all. This isn't a race for the bottom, trying to find the lowest common denominator. Not everything can run on every storage engine (otherwise the only possible option is to only design Django to work with CSV files, since everything else has some features that storage system doesn't). -- Malcolm Tredinnick''

47

47

48

''What's the problem exactly? I don't see a lot of cases where this would break assumptions. At the Model level it's fully abstracted away, anyway. As long as you don't make explicit queries against the underlying tables, but just work with the models it will be 100% the same behavior. Also, the alternative is that the code doesn't work, at all, on App Engine, so it's better to have 50% of all Django apps that use multi-table inheritance work correctly than 0%. -- wkornewald''