*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.
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. 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? 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. *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). 2) Currently unknown level of effort or complexity to allow the migrations to fallback to a Django 1.6 syncdb-esque behavior. *Feedback* Please share your questions and comments on the mailing list. Regards, Michael Manfre [1] https://code.djangoproject.com/ticket/21841 -- 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/CAGdCwBt13g_X6W5SLWVBvQGrSdu7o7D8Oh2HzUercJQe4_6RwQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
