On 30 touko, 21:03, Andrew Godwin <and...@aeracode.org> wrote: > 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).
+1 to #3. I haven't used South as much as I should have (instead I have painful manual scripts to do migrations). The biggest pain point about database schemas for me is easily test database setup. That is, sync from scratch. I do the following currently: 1. load schema + a little bit of data from production through pg_dump + pg_restore. The data is mostly metadata, in particular already applied migrations in production. 2. run those migrations that haven't been applied already. Will I be able to do the above somehow? Will #3 do a similar thing for test database setup, except that you run all migrations against empty database? The first migration would be the initial "syncdb", and then you run rest of the migrations in chain finally arriving to the wanted database state. Or would it be "sync" all models, then run migrations against that database? Sorry if these are stupid questions... I really do not know South as well as I should, so I need a little tutoring... - Anssi -- 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.
