OK, I've now run into the problem IRL, and sure enough, it's different to
what i'm used to. Am trying to overcome my knee-jerk reactions of "why did
it change! i hate it!". ignoring that for a moment then:
One thing I did find surprising was that I'm going thru TDD in small steps
like this:
class Item(models.Model):
pass
- create migration 001-initial, with Item and auto-id
class Item(models.Model):
text = models.TextField()
- create migration 0002, adding the item field. here's where we get into
the discussion of too many migrations, wanting to squash, etc etc etc.
leaving that aside for a moment, i was taken aback by this:
You are trying to add a non-nullable field 'text' to item without a default;
we can't do that (the database needs something to populate existing rows).
Please select a fix:
1) Provide a one-off default now (will be set on all existing rows)
2) Quit, and let me add a default in models.py
I thought TextField did have a default, the empty string?
On 29 March 2014 19:15, Harry Percival <[email protected]> wrote:
> I suspect you're probably right. Having to run makemigrations in between
> making changes to model code and running tests isn't the end of the world i
> suppose. Will know better what I'm talking about when I've actually got
> to that part of the book...
>
>
> On 29 March 2014 18:23, Andrew Godwin <[email protected]> wrote:
>
>> 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 <[email protected]
>> > 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 <[email protected]
>>>> > 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].
>>>>> 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/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<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 a topic in the
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/PWPj3etj3-U/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAFwN1uoqPk47Zbd7fDA9pP3VyJ5xw%2B4UciBffD-jgKq88i4MJQ%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAFwN1uoqPk47Zbd7fDA9pP3VyJ5xw%2B4UciBffD-jgKq88i4MJQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> ------------------------------
> Harry J.W. Percival
> ------------------------------
> Twitter: @hjwp
> Mobile: +44 (0) 78877 02511
> Skype: harry.percival
>
--
------------------------------
Harry J.W. Percival
------------------------------
Twitter: @hjwp
Mobile: +44 (0) 78877 02511
Skype: harry.percival
--
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/CACFvh9-y8NZ-KVg9SkCxiw6Wm5h5nVptCT%2BthmPTWKC5gkXdPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
