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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
