Opened 14 years ago
Closed 12 years ago
#15124 closed Bug (fixed)
BooleanField should not use False as default (unless provided)
Reported by: | Andrew Badr | Owned by: | Aymeric Augustin |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 1.4-alpha-1 |
Severity: | Normal | Keywords: | |
Cc: | andrewbadr.etc@…, Łukasz Rekucki, to.chomik@…, lpiatek, botondus@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Steps to repro:
1) Make a Model with a BooleanField with no default
2) Instantiate that model with no initial value
3) The value of the BooleanField on that instance is False
Expected behavior:
3) The value of the BooleanField on that instance is None
Guessing a value for the field is wrong. Attempting to save a model with a non-null field without providing a value for that field should be an error. (Postgres of course throws an error if you try to insert a row with no value for a required bool field.) It's ok for CharFields with blank=True to default to the empty string, because that's semantically the lack of a value for the field. However, True and False are equals; False is not the lack of a value.
Note the existence of the opposite ticket, #2855, which was wontfix'd then apparently silently "fixed" at some point.
Attachments (7)
Change History (24)
comment:1 by , 14 years ago
Cc: | added |
---|
comment:2 by , 14 years ago
Component: | Uncategorized → Database layer (models, ORM) |
---|---|
Triage Stage: | Unreviewed → Design decision needed |
comment:3 by , 14 years ago
Has patch: | set |
---|---|
Version: | 1.2 → 1.3-beta |
comment:4 by , 14 years ago
So apparently I hadn't noticed this before, but this will almost certainly break code I have, likely others as well.
comment:5 by , 14 years ago
Likely, but the current behavior is (1) wrong, (2) undocumented, (3) arguably untested, and (4) has already changed in the past. The bug should be fixed for 1.3 but (as Russ says) not backported.
comment:6 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:7 by , 13 years ago
Easy pickings: | unset |
---|---|
Triage Stage: | Design decision needed → Accepted |
UI/UX: | unset |
I just read the thread and it seems to me that the majority is in favor of fixing this bug.
comment:8 by , 13 years ago
Cc: | added |
---|---|
Needs documentation: | set |
Triage Stage: | Accepted → Ready for checkin |
Version: | 1.3-beta → 1.4-alpha-1 |
Works ok. Tests and docs are there, so RFC.
by , 13 years ago
Attachment: | 15124ticket.diff added |
---|
Fix with tests and docs with realease notes for 1.4-beta-1 instead of 1.4
comment:9 by , 13 years ago
Cc: | removed |
---|---|
Triage Stage: | Ready for checkin → Accepted |
by , 13 years ago
Attachment: | 15124ticket.v2.diff added |
---|
change marked as backwards incompatibile in release notes
comment:10 by , 13 years ago
Cc: | added |
---|
comment:11 by , 13 years ago
Cc: | added |
---|
by , 13 years ago
Attachment: | 15124ticket.v3.diff added |
---|
corrects 15124.v2 FlatPage BooleanFields to have default value
comment:12 by , 13 years ago
Cc: | added |
---|
by , 13 years ago
Attachment: | 15124.updated.patch added |
---|
Combined and updated prev. patches to apply cleanly. Added doc entry to model fields
comment:13 by , 13 years ago
Cc: | added |
---|---|
Needs documentation: | unset |
comment:14 by , 13 years ago
My take here is that this is a legitimate bugfix and should go in, but there's enough potential for breakage of existing code that I'm hesitant to drop it in after the beta, I'd rather target it for 1.5 at this point.
comment:16 by , 13 years ago
Owner: | changed from | to
---|
comment:17 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Discussion on django-dev