No, there is no way to turn off migrations for tests - some of the core tests won't work without them turned on, in fact, and adding that option would be weird (why only tests? what would it do? how do you load data in now initial_data is gone?). The only complaint I've seen - the one that Bernie brought up originally, that it's "extra work" to run makemigrations before each test run - doesn't really hold water with me, as the alternative options mean you could run the tests and have them pass WITHOUT HAVING THE RIGHT MIGRATIONS - and so you're not testing part of your codebase.
Hell, you can alias together makemigrations and test if you want, that'll save you the typing. This might make a few more migrations than normal, but you could quickly point out that squashmigrations exists to deal with this problem and move on. Andrew On Sat, Mar 29, 2014 at 9:42 AM, Harry Percival <harry.perci...@gmail.com>wrote: > Am just working on updating my book on TDD to django 1.7 based on the > beta. Currently half-way thru, not run into any problems because I don't > use migrations until a later chapter, but when I do I will run into the > same problems Bernie mentions. > > Will share more once I've finished the rewrites, but from what I see so > far, I think I'd personally prefer to be able to run my tests without > having to remember to call makemigrations every time. some kind of > customisable option? either a command-line flag for the test runner, or > maybe a setting in settings.py, eg MIGRATIONS_OFF_FOR_TESTS = True? > > personally i'd like the default to be true, but i can appreciate other > people will have different workflows / assumptions. > > > > > On Friday, 28 March 2014 16:48:52 UTC, Andrew Godwin wrote: > >> Yes, --update is very risky if you run it on migrations that are already >> committed and pushed, but the main reason I left it out of 1.7 was >> complexity (because makemigrations is now much more intelligent, updating >> and adding a foreignkey into a migration might introduce a new dependency >> or force a new migration anyway). Given that we have the ability to safely >> squash large numbers of small migrations down into one with >> squashmigrations and distribute that to fix the many-small-migrations >> problem, I considered it pretty low priority, though I have a rough idea of >> how I could make it work (I'd have to load up the autodetector with the >> existing migrations already loaded in as a halfway state and then run it >> from there, which should produce the right result). >> >> Anyway, if you're retracting your original request, I'm happy to leave >> this for the 1.7 release; I don't think there's a good solution that Django >> core can implement effectively. This reminds me of when people used to ask >> me to automatically stop their developers writing conflicting migrations - >> the solution varies from company to company and often isn't technical but >> just education or communication. >> >> Andrew >> >> >> On Fri, Mar 28, 2014 at 4:46 AM, Bernie Sumption >> <ber...@berniecode.com>wrote: >> >>> South's `--update` also rolled the previous migration back, changed it >>>> and then reapplied it to the current database. >>>> >>> >>> OK, in that case I can very much see how it's useful for people who >>> develop against a persistent database. That's probably most people. >>> >>> Anyway, the result of this thread for me is that I now consider my >>> original request to be obsolete, as the "git clean" thing is a simple way >>> of getting the behaviour I want for my own style of TDD without hacks. >>> >>> Thanks for your time. >>> >>> Bernie :o) >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/8e3ecf3c-aa05-4e3d-b905- >>> 3260b093e046%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/8e3ecf3c-aa05-4e3d-b905-3260b093e046%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a2897318-ec81-4acd-b201-2591042db1a0%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/a2897318-ec81-4acd-b201-2591042db1a0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1uoqPk47Zbd7fDA9pP3VyJ5xw%2B4UciBffD-jgKq88i4MJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
