+1 for disabling migrations completely - for several reasons. 1. Right now, I'm trying to run tests against a production database with runserver, in *read-only* mode - but it fails because it can't create the django_migrations table. (I'm in the process of upgrading from Django 1.4 to 1.8, so the table doesn't yet exist in production.)
2. Our mysql database is 3TB, with some tables of up to 500GB - and I assume that migrating them with Django - without taking the system down for days - is not possible. Instead, we use Percona's pt-online-schema-change, which does an excellent job of migrating big tables, whilst keeping them fully usable with no downtime. Point 2 is covered, I think, by setting all models to unmanged, as we do - but that doesn't help me with the upgrade process in point 1 - unless I'm missing something? (Yes, perhaps I could jump through hoops and make a second, writable database, with appropriate routers etc, to enable creation of the django_migrations table, to get past point 1 - but if django migrations are useless to us anyway... disabling migrations entirely seems far more logical.) -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/de1ad2dc-10e5-4f95-8f7b-1075c268e2ac%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
