On Wed, Jan 22, 2014 at 3:59 PM, Shai Berger <[email protected]> wrote:
> Hi, > > (quotations reordered a little) > > On Wednesday 22 January 2014 14:48:25 Russell Keith-Magee wrote: > > On Wed, Jan 22, 2014 at 1:51 PM, Michael Manfre <[email protected]> > wrote: > > > *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. > > > > I was going to say that the argument confuses the backend level with the > project level. Russell beat me to it :) > > > > 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". > > > > +1 Russell, again. > > > 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. > > Actually, SQLite "doesn't support altering the schema in a way that would > work > with Django's schema migrations API". The SQLite backend bends over > backwards > to comply; its implementation of "alter column" is "recreate the table, > copying the data". AFAIK it doesn't quite get everything right, even with > the > somersaults it pulls; and yet, it's close enough for comfort. > > So, in order to really count as "can't support", a backend needs to be > crippled to a level where implementing django-1.6-syncdb is probably > impossible as well. > > > > > There's also option 4: The developer of a particular backend doesn't have > > the time or inclination to add support for migrations. > > > > which brings me back to > > > > 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. > > > > > and > > > > *Potential Issues With Optional Support* > > > > > > 2) Currently unknown level of effort or complexity to allow the > migrations > > > to fallback to a Django 1.6 syncdb-esque behavior. > > An alternative, which I think will have much lower costs, and send the > right > message about such backends is: > > A) Django only changes the schema through migrations; if you don't want > migrations in your backend or your project, than the schema changes need to > happen some other way, using an external tool. > > B) Allow the test suite to run on an existing schema. The Oracle backend > already does this (badly) -- its six specific TEST_* parameters are > awkwardly > named, but allow you to say exactly which schema to use for testing, and > whether or not you want it created. If this is made more general, then > testing > can be made to not depend on migrations; with no migrations, you will > need to > take care of the test database yourself -- just like you take care of the > production database. > > For Django's own test-suite, tests which need migrations can even be > automatically skipped if getting a schema_editor raises a > NotImplementedError; > allowing a backend to easily (well, relatively easily) pass the suite > without > implementing migrations. > This last bit is the critical part. At present, we don't have any infrastructure to allow tests to be skipped because of a lack of migration support. All Django's officially supported backends support migrations, so there hasn't been any need to skip any tests. The question is whether we should allow for this for third party backends. Historically, the test for a "Django 1.X supported backend" has been "Passes the Django 1.X test suite without errors."; database features have been added to allow checking for specific known problems on specific backends (vendor-specific index name size limits, for example), but not for entire features. The proposal here is to provide a similar flag for migrations, enabled for all the builtin backends, so that you could have a "compliant" 1.7 database backend without supporting migrations. I'd argue this isn't something we want to encourage. 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/CAJxq849hHcz5EFLmqfaFDZDAz_Em3NCPvc%2B_MKKV2OwMJ9E7TA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
