2014/1/22 Michael Manfre <[email protected]> > Currently unknown level of effort or complexity to allow the migrations > to fallback to a Django 1.6 syncdb-esque behavior. >
Assuming that cost isn't too high, another concern is our ability to maintain this feature: since none of the core backends will use it, it may fall behind. For your production use case, you could get away with `./manage.py sqlall` which is unchanged in 1.7. That will give you a new schema you can diff with the current schema. If I understand your point regarding Django's test suite, it doesn't even start because it uses the migration API to create the tables. You could probably solve that with a custom test runner that overrides table creation, basically to pipe the output of `sqlall` to the database. That area of the code base isn't particularly complex. Let's discuss on IRC if you need pointers. Assuming this workaround provides a short term solution, it may be bundled with the database backends that need it. I think that would be good enough. I share Russell's concern about endorsing a partial solution. I hope this helps, -- Aymeric. -- 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/CANE-7mVtj%2BRw712pMDXwR7i0V%2BkFjOia3_huSkWAHheDvgbP7g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
