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 > <[email protected]<javascript:> > > 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 [email protected] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> 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 [email protected]. To post to this group, send email to [email protected]. 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. For more options, visit https://groups.google.com/d/optout.
