Hacker News Reader

Comment by VuongN | Hacker News Reader

I have to say that I've been a big Django user and have been using 1.7.x for a bit in my own development. There are a couple of "oddities" for me that perhaps folks will encounter:

1. If you do heavy TDD, you might not like that fact that you can't skip migrations the same way you previously could with SOUTH_TESTS_MIGRATE = False. There's a thread going on (https://groups.google.com/forum/#!topic/django-developers/PW...). It appears that with syncdb going away, there isn't an option available. I really hope there's a way to retain syncdb for unittest because I don't need to test database migration every time I run my quick unittests.

2. I think 'makemigrations' is a bit inconsistent at the moment. Sometimes it creates more than 1 initial files, sometimes it creates just 1 (if you run 'makemigrations app-name' instead of 'makemigrations')

There are a couple of other general Django issues, but those are the things I encountered while working with 1.7.x.

View on HN

> you might not like that fact that you can't skip migrations the same way you previously could with SOUTH_TESTS_MIGRATE = False.

Note that it's possible to squash a long series of migrations to just one "CREATE TABLE" version: https://docs.djangoproject.com/en/dev/topics/migrations/#squ...

After squashing, the new all-in-one migration should be used for tests, and should be more or less identical to syncdb.

1. I think I'd like to see something like `./manage.py migrate --fresh`, which would forget about existing migrations, create a set in memory, and apply them. Pretty much emulating syncdb on a fresh database. Then the test runner could use that behaviour optionally (otherwise, RunPython statements may be missed that are required).

2. It may create more than 1 migration file if there are specific ordered dependencies afaik.

Using its best guess with dependency, it creates the appropriate migration file(s) favoring more files over potential conflicts. I think that's fine. The problem is consistency. However you choose to run the makemigrations, it should at least result in the same amount of files. It can't be more or less conflict if nothing is changed.

Does migration squashing do what you are looking for: https://docs.djangoproject.com/en/dev/topics/migrations/#squ... ?

After squashing and migrating all existing databases, you can delete the old migrations files. The squashed migration becomes the new fresh migration that should usually contain just "CREATE TABLE" statements to be run on an empty database.

Not sure if it solves your problem, but in the dev version of Django you can use the `--keepdb` flag to `manage.py test`. This will preserve your test database after the test run, and only run any new migrations. It gives a real speed boost.

and also lot of headaches :)

My old test runner allowed me to reuse the database for tests. That's ideal for quick testing.

Reply on news.ycombinator.com