Hi all, On Thursday 30 May 2013, Andrew Godwin wrote: > > The proposals are: > > 1. Change syncdb so that it both does the old behaviour (adds models for > unmigrated apps), and additionally runs any outstanding migrations. There > would be a separate "migrate" command for more complex operations, such as > reversing them or faking application, which is a little odd. > > 2. Leave syncdb as it is, like South does, and have everything happen > through a "migrate" command. Leads to weird interactions where each command > knows about the other, and must be run in a certain order, but which isn't > immediately obvious. > > 3. Do everything through a single command - migrations, non-migrated > syncing, reversal of migrations, etc. I would call this command "migrate", > and start a deprecation cycle on "syncdb" (which would turn into an alias > to "migrate"). Calling "./manage.py migrate" would first sync unmigrated > apps, and then run migrations, but would have options so a user could > migrate (or sync!) specific apps/target migrations. > Naming aside, I see little value in an operation that runs the current syncdb without running pending migrations. Thus, -1 on option 2.
Between 1 and 3, I tend towards 3, assuming that the default operation (that is, with no flags or arguments) is the equivalent of South's current "syncdb --migrate" -- that is, the syncdb of option 1. I don't like the current situation, where syncdb without --migrate is not useful and migrate requires an explicit choice of apps. Shai -- 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 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
