Opened 7 months ago
Last modified 6 months ago
#35223 closed Cleanup/optimization
Fields with db_default raise ValidationErrors when full_clean() called — at Version 2
Reported by: | Brian Ibbotson | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 5.0 |
Severity: | Release blocker | Keywords: | |
Cc: | Brian Ibbotson, bcail | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Starting to migrate models in my (large) project to use Django 5’s new db_default
attribute for fields (using Django 5.0.2), encountering behavior contrary to my expectations.
A field with db_default
raises a ValidationError
when full_clean()
called, if that field has been omitted from the create()
call.
This is (to me) unexpected behavior. Would expect that no error would be raised, the instance would be saved successfully, with the specified db_default
value set at the database level.
Has been explained to me in the Django forums that the ValidationError
is correct, that I should instead either
(1) explicitly choose to exclude
the missing fields from full_clean()
call,
(2) write a custom clean method for each field, or
(3) simply save the instance rather than calling full_clean()
Had always been impressed on me that it is best practice to always call full_clean()
on instance creation and/or update.
In either case, having to determine the missing fields and annotate the full_clean()
call or write a custom clean method per field seem to work against the usual conception of a default value, which should propagate... well, by default and allow for simpler operation where possible.
I would suggest having fields with db_default
be excluded by default from full_clean()
If the current behavior is re-affirmed, would suggest incorporating the suggested 3 workaround steps into the Django documentation, as I suspect most users would have similar expectations as myself when implementing this in future code.
Change History (2)
comment:1 by , 7 months ago
Description: | modified (diff) |
---|
comment:2 by , 7 months ago
Description: | modified (diff) |
---|