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 [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.
