Opened 18 years ago
Closed 12 years ago
#3997 closed Bug (fixed)
Missing default value causes exception on save
Reported by: | Owned by: | Philippe Raoult | |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | doc |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description
Using MySQL I have noticed a common cause for save to fail. Especially BooleanField's with no default value. If there is no default value, MySQL will return a Warning for data truncation, which will cause the save to fail. I believe that I tried to catch MySQLdb.Warning and pass on it with no improvement.
1) A warning should not cause the transaction to fail
2) If a default value is effectively required, validate should check for it
Attachments (2)
Change History (11)
by , 17 years ago
comment:1 by , 17 years ago
Has patch: | set |
---|---|
Keywords: | doc added |
Owner: | changed from | to
Status: | new → assigned |
Triage Stage: | Unreviewed → Ready for checkin |
The patch only adds a note to the doc. An empty Boolean fields will cause validate() to fail and save() to raise as expected.
comment:2 by , 17 years ago
Patch needs improvement: | set |
---|---|
Triage Stage: | Ready for checkin → Accepted |
A couple of things about this patch:
validate()
doesn't work totally at the moment, so documenting it's existence would be premature. That is work-in-progress.- We should try to work out 'which' types of error save() might raise, if possible, so that code can catch them if they want to. IntegrityError from the db layer is one.
I'm not totally onboard with MySQL's idea that storing inconsistent data is only a warning and not an error. I'm not sure we're behaving incorrectly there, at least in the sense that trying to save invalid data is bad.
by , 17 years ago
Attachment: | 3997_2.diff added |
---|
comment:3 by , 17 years ago
Patch needs improvement: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
- removed the reference to validate()
- I added the exceptions I would find, and mentionned that it'd DB dependent.
Until we stop relying on the DB to do the checking for us there's nothing more we can do here.
comment:4 by , 17 years ago
Triage Stage: | Ready for checkin → Accepted |
---|
Saying "database independant" is a bit ugly, we should catch the different exceptions and raise one common for every backend unless we want people to either catch only the one they care about (the backend they're using) or have to deal with all of them.
Anyway I'd go for setting up "traditional mode" in MySQL by default... here, note the joke in "Make MySQL behave like a “traditional” SQL database system. A simple description of this mode is “give an error instead of a warning” when inserting an incorrect value into a column."
comment:5 by , 15 years ago
Patch needs improvement: | set |
---|
Seems like there's still dispute on the best way to solve this.
comment:6 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:9 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I think this may be addressed given https://docs.djangoproject.com/en/dev/releases/1.6/#booleanfield-no-longer-defaults-to-false
note in the model api doc about that ...