#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 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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/35223#comment:2>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018db39a9d48-fec631d2-e24b-4943-b2cc-943d0c9cf917-000000%40eu-central-1.amazonses.com.
