On 05/30/2013 12:03 PM, 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. > > I prefer option 3, but getting rid of syncdb might be controversial, so > I want to ask for people's opinions. syncdb would continue to exist for > at least 3 versions if not forever; it would just be an alias to run > "migrate" in its default configuration, and would do exactly what you > would expect (whereas with South now, and with option 2, syncdb doesn't > do enough).
I much prefer option 3; I think a deprecation path for syncdb is fine. It's always been mis-named anyway, since it doesn't really sync. Carl -- 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.
