``models.BooleanField`` fields default to ``False`` when missing from fixtures

[Yo-Yo Ma]

This may be the intended behavior, but I couldn't find docs on it. My recommendation would defer to "The Zen of Python"

    In the face of ambiguity, refuse the temptation to guess.

I would rather see the typical IntegrityError: Problem installing fixture...

[Aymeric Augustin]

2012/9/24 Yo-Yo Ma <baxters...@gmail.com>

This may be the intended behavior, but I couldn't find docs on it. My recommendation would defer to "The Zen of Python"

    In the face of ambiguity, refuse the temptation to guess.

I would rather see the typical IntegrityError: Problem installing fixture...

Hello,

This looks a lot like: https://code.djangoproject.com/ticket/15124

I hope I'll have time to study this problem again before the feature freeze of 1.5.

--
Aymeric.

[Yo-Yo Ma]

Yep, that looks like it. IMHO, this is a bug that should be fixed without delay, as it breaks a cardinal rule for Pythonistas, and could even lead to a "data corruption" situation, if a dev was to add a boolean field and forget to update a form or fixture, or both.

[Florian Apolloner]

On Monday, September 24, 2012 3:07:37 PM UTC+2, Yo-Yo Ma wrote:

Yep, that looks like it. IMHO, this is a bug that should be fixed without delay, as it breaks a cardinal rule for Pythonistas, and could even lead to a "data corruption" situation, if a dev was to add a boolean field and forget to update a form or fixture, or both.

I don't see how that could corrupt stuff in the current situation, I'd rather argue that fixing the bug will cause more issues since people probably (I am sure I do) do unknowingly rely on the current behavior. As such we will exercise caution here and won't commit it in a rush just to get it in… Aside from that we obviously agree that it should get fixed ;)

[Aymeric Augustin]

2012/9/24 Florian Apolloner <f.apo...@gmail.com>

I don't see how that could corrupt stuff in the current situation, I'd rather argue that fixing the bug will cause more issues since people probably (I am sure I do) do unknowingly rely on the current behavior. As such we will exercise caution here and won't commit it in a rush just to get it in… Aside from that we obviously agree that it should get fixed ;)

Yes, thousands of sites must be relying on the current behavior. That's the reason why the bug isn't fixed yet.

--
Aymeric.

[Yo-Yo Ma]

Developer of a pet shop software adds:

feed_before_midnight = models.BooleanField()

because they're planning on carrying baby gremlins... forgets to update the zoological XML feed importer to use the "feed_before_midnight" value, and the rest is history :)

On Monday, September 24, 2012 9:21:34 AM UTC-4, Florian Apolloner wrote:

...

[Russell Keith-Magee]

On Tue, Sep 25, 2012 at 8:00 AM, Yo-Yo Ma <baxters...@gmail.com> wrote:
> Developer of a pet shop software adds:
>
> feed_before_midnight = models.BooleanField()
>
> because they're planning on carrying baby gremlins... forgets to update the
> zoological XML feed importer to use the "feed_before_midnight" value, and
> the rest is history :)

We need to be clear on what we (as in, the Django project) classify as
"catastrophic data loss".

Examples of Catastrophic data loss:
* You request a save of object X, and object X is not saved.
* You save object X, and object Y is modified.
* You save object X, and object Z is deleted.

NOT examples of Catastrophic data loss:
* You forget to set a value on an object, and the default isn't what
you expected.
* You set a value on an object, which is saved verbatim, but wasn't
the correct value under the circumstances.

In the example you provide, I agree that there would be catastrophic
consequences. However, the code is doing exactly what it's instructed
to do. While I may concede that this is a bug, it's a bug caused by
ambiguous default behaviour, not behaviour that is fundamentally
incorrect or destructive -- it's essentially nothing more than "0 is a
default value". You can argue that 0 isn't an appropriate default in
this circumstance, but you can't argue that it is (a) a particularly
surprising default, or (b) that the developer was given an opportunity
(multiple opportunities, really) to set an appropriate default.

If this conflicts with what you consider to be catastrophic, thats
fine -- I'm just letting you know the benchmark that we, as a project,
use to guide our decision making process.

Yours,
Russ Magee %-)

[Yo-Yo Ma]

The gremlin example was just a light-hearted attempt at justifying the claim of "data corruption", in response to Florian, but I really only brought up this issue because it surprised me (nothing in the docs).

I would suggest a docs update to let developers know that if a default isn't set, ``False`` is implied - only because this seems like the sort of mini-"bug" that might never warrant fixing due to the ramifications.