#35223: Fields with db_default raise ValidationErrors when full_clean() called
-------------------------------------+-------------------------------------
Reporter: Brian Ibbotson | Owner: nobody
Type: Bug | Status: new
Component: Database layer | Version: 5.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Brian Ibbotson:
Old description:
> 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 this 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.
New description:
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 this 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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35223#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018db3999ef9-c470e772-ef1c-4193-8bfb-f0c404a3d4c2-000000%40eu-central-1.amazonses.com.
