On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre <[email protected]> wrote:
> *Must a Django Database Support Migrations?* > > Django 1.7 adds schema migration support and this behavior is currently > required > to be able to effectively use Django and run the test suite. I opened > ticket > #21841 [1], which requests adding a DatabaseFeature to disable schema > migrations. This ticket prompted an IRC discussion between Russell and > myself > that ended with the question, must a database backend support schema > migrations > to be compliant with Django 1.7? We're hoping to get opinions from others > about > this to figure out how to proceed. > I'm weighing in here to give my side of the argument :-) > Database backend compliance is defined by its ability to pass Django's test > suite. A fully compliant database can pass 100% of tests dealing with the > database. If a database backend raises NotImplementedError for > schema_editor, it > is currently 0% compliant because it cannot create the database tables. > > If database backends are not required to support migrations, then there > would > need to be some form of fallback behavior to provide a Django 1.6 > syncdb-esque > behavior. It would create the schema without attempting alterations. > > *Why Disable Migrations?* > > 1) Not all projects need schema migrations or want Django to manage the > migrations. My primary project has Django working against a legacy > database and > relies upon an external tool (and a DBA) to manage schema changes in our > environment. This workflow uses syncdb to create the tables in to a > temporary > database and then compares it will an external tool that generates an SQL > diff. > This diff is tested by the DBA before being applied to the production > database. > This basic workflow will continue even after upgrading to Django 1.7. > > This scenario does not necessarily need to be handled as a database > feature. > Russell's idea during the IRC discussion was a database configuration that > acts > as a safety to prevent migrations from being applied; similar to managed > models. > I have no problem with this use case. My problem with the specific proposal in #21841 is that the database backend is the wrong place to be making this distinction. The decision as to whether the backend supports migrations is independent of whether the user wants to use them. The PostgreSQL supports migrations; that doesn't mean I want to use them. If model-level Meta.managed isn't enough to disable migrations, then a settings.DATABASES flag may be called for, but that's different to what was originally proposed. > 2) NoSQL databases don't necessarily have an enforced schema. What would > migration mean for NoSQL? Would it noop or attempt to update existing > data? Do > we even care because NoSQL is not officially supported by Django? > This is a problem that we don't have (since we don't support NoSQL), so the question is completely hypothetical. However, I don't have any difficulty believing that the *concept* of migrations could exist on NoSQL databases - the implementation just won't look anything like "ALTER TABLE ADD COLUMN". This means we're really only left with: > 3) The database backend or driver doesn't support altering the schema in a > way > that would work with Django's schema migrations API. I can't think of any > that > would be used with Django, but people still use mysql despite its many > faults, > so anything is possible. > This one, which seems unlikely. SQL is a pretty fungible standard, and yet we've been able to coerce SQLite, MySQL, PostgreSQL and Oracle into the task. From what I *do* know about the migrations implementation, it's largely driven by high level primitives -- add a column, remove a column, alter a column etc. These high level primitives don't enforce anything significant on the underlying SQL -- and if it does, I'd argue that's a bug in the abstraction. There's also option 4: The developer of a particular backend doesn't have the time or inclination to add support for migrations. > *Potential Issues With Optional Support* > > 1) If migration support is optional, a concern was raised that backends > that > don't support it would give users a lesser experience and potentially make > Django look bad. > > While this might be possible, the same concern holds true for any existing > database backend that is buggy, doesn't fully implement the existing API, > or the > underlying database itself is slow or lacks basic functionality (e.g. > referential integrity, ACID compliance, etc). > This is true, but at that point we can point at the database and say "it's not our fault". MySQL *does* do dumb things with indexes (and subqueries, and referential integrity, and.… :-) Oracle *is* slow to do certain table setup operations. That's not our fault, and we can assign blame/point out limitations as appropriate. If we explicitly add APIs that allow people to say "I've got a Django 1.7 compliant database API, but it doesn't support most of the API", then we've explicitly given permission for people to half-ass things, and that's something we *do* have to accept blame for. If we have this API, people will produce non-migrating 1.7 backends, and then we'll have ghettos in the community that can't use the banner features of 1.7. Yes, adding migrations is a big thing, so writing a Django 1.7-compatible database backend will be a big task. But I don't see the value in providing a way to explicitly support a half-way solution. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_DhMjAFggugv365fcQiXOCAN2HX3yv3r%3Dnhc051ttZBA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
