If makemigrations exits with something other than 0, it will not have created any migrations to run anyway, so running the makemigrations & migrate pair here would not be affected. However, a useful one liner that I have been using when developing is:
./manage.py makemigrations && ./manage.py migrate && ./manage.py runserver If the exit code was always used, chains like this would become much more awkward to use, which is why my preference is for option 2 or 3. Making migrations and not applying them is useful if you want to review or edit the migrations before applying them - perhaps to split the migration in to two logical chunks for two different commits, or to append some manual migration code to the automatically generated migration. As part of continuous integration I also want to run: ./manage.py makemigrations --dry-run --exit || fail-build "Outstanding database changes with no migrations" This way, the build fails if there are outstanding migrations. I am not interested in creating or running migrations in this instance, just checking that everything is up to date. On Thursday, October 30, 2014 12:21:11 PM UTC+11, Daryl wrote: > > I'm +1 on being able to continue using the line > ./manage.py makemigrations && ./manage.py migrate > > I can't see many (any?) situation where someone *wouldn't* run > makemigrations & migrate as one logical operation, whether by typing > the commands or running a script. > What would the workflow be where you would make migrations but not apply > them? > > D > > > > On 30 October 2014 12:29, Tim Heap <t...@timheap.me <javascript:>> wrote: > > The backwards compatibility issue I was thinking of is for people using > > `makemigrations` in a script currently, expecting it to exit with 0 > unless > > something very wrong has happened. For example, if `makemigrations` is > run > > in a bash script with `set -e`, and it does not find any migrations, > that > > script will then exit. Alternately, if someone is using a one-liner like > > `./manage.py makemigrations && ./manage.py migrate && another command` > the > > makemigrations command will cause the whole command to abort early, even > > though no 'error' as such has happened. Backwards compatibility aside, > this > > would be awkward to work around in scripts without simply ignoring the > exit > > code of `makemigrations` completely, which then ignores legitimate > errors. > > > > I have made a patch that calls `sys.exit(1)` when no changes are found, > and > > made a pull request at https://github.com/django/django/pull/3441 > > > > Tim > > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/102bf2cd-f843-4dac-9374-6d1f5d20c59f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
