Creating in-memory migrations for all apps that don't have migration files seems to be an option to solve the dependency problem. This would even allow apps without migrations to depend on those with migrations.
We have to consider though, that there are tens of apps and hundreds of models in our own test suite, and generating all migrations during start seems to be quite an expensive task. And I'm not even talking about the migration optimizer which probably needs to get a lot smarter if we take this road. syncdb, which leaves a developer with a database scheme that cannot be altered automatically, is something we should get rid of as soon as possible, especially since Django has a out-of-the-box migration system. /Markus On Sun, Jan 18, 2015 at 01:50:14PM -0800, Andrew Godwin wrote:
My main argument for removing them entirely was the dependency issues between apps with and without migrations. Having syncdb use SchemaEditor is a big step and one I'm happy we've got to, but the only advantage of keeping syncdb is for the test suite and I'd rather we approach that more as "migrations made and run at runtime as a special case" rather than "syncdb". If nothing else, I'd like to see the end-developer-facing parts, like the syncdb command itself, gone. Andrew On Sun, Jan 18, 2015 at 1:43 PM, Claude Paroz <cla...@2xlibre.net> wrote:Tim recently did a fabulous job of removing deprecated code for the future 1.9 on master. Thanks for that. However, one thing he removed was support for apps without migrations. https://github.com/django/django/commit/7e8cf74dc74539f40f4cea53c1e8bba82791fcb6 Considering that we have to keep internal support for Django's own test suite anyway, I wonder if we should remove that support at all for "normal" projects. I think one of Andrew's motivation was not to have to keep two schema editing code bases. But now that the old syncdb also uses the new schema editor, I think that this argument doesn't stand. So what about keeping support for apps without migrations in the longer term. Of course, the fact that those apps cannot depend on migrated apps limits its use, but I think that for quick prototyping and initial developement, migrations could be more of a hindrance. Would you see major drawbacks with keeping this support? Opinions welcome. Claude -- www.2xlibre.net
-- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/20150118221144.GA31780%40pyler.local. For more options, visit https://groups.google.com/d/optout.
pgpRKu9huGEzV.pgp
Description: PGP signature