Changes between Version 24 and Version 25 of NonSqlBackends


Ignore:
Timestamp:
Oct 16, 2009, 10:40:03 PM (15 years ago)
Author:
Malcolm Tredinnick
Comment:

Pointed out some problematic assumptions

Legend:

Unmodified
Added
Removed
Modified
  • NonSqlBackends

    v24 v25  
    4444TODO: How do we store field data that doesn't exist in any model definition?
    4545
     46''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
    4648== save_base() ==
    4749
Back to Top