Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  bcail
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak ):

 In [changeset:"5f07460a67825bfc3f0129feec94a24bbf6d2a5f" 5f07460a]:
 {{{#!CommitTicketReference repository=""
 revision="5f07460a67825bfc3f0129feec94a24bbf6d2a5f"
 [5.0.x] Fixed #35223 -- Made Model.full_clean() ignore fields with
 db_default when validating empty values.

 Thanks Brian Ibbotson for the report.

 Regression in 7414704e88d73dafbcfbb85f9bc54cb6111439d3.

 Backport of 1570ef02f34037d32218d463342592debccf915c from main.
 }}}
-- 
Ticket URL: 
Django 
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/0107018e1c9a2837-bcdc5eec-3b47-4a7d-883d-29bc33fa2dad-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  bcail
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * resolution:   => fixed
 * status:  assigned => closed

Comment:

 In [changeset:"1570ef02f34037d32218d463342592debccf915c" 1570ef0]:
 {{{#!CommitTicketReference repository=""
 revision="1570ef02f34037d32218d463342592debccf915c"
 Fixed #35223 -- Made Model.full_clean() ignore fields with db_default when
 validating empty values.

 Thanks Brian Ibbotson for the report.

 Regression in 7414704e88d73dafbcfbb85f9bc54cb6111439d3.
 }}}
-- 
Ticket URL: 
Django 
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/0107018e1c97f097-cf3ddf8a-87d2-4f75-ba34-631c348f01dd-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  bcail
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Damir Nafikov => bcail
 * stage:  Accepted => Ready for checkin

-- 
Ticket URL: 
Django 
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/0107018e18e97779-1e1373b5-3f7e-4faf-9bbe-2318672a2162-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  Damir
 Type:   |  Nafikov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak):

 Bug in 414704e88d73dafbcfbb85f9bc54cb6111439d3.
-- 
Ticket URL: 
Django 
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/0107018e18e08cb9-3339a400-8fea-421e-bd5f-74d1b29cd399-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  Damir
 Type:   |  Nafikov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * severity:  Normal => Release blocker

Comment:

 Bumping to a release blocker as `Model.full_clean()` crashes on some
 expressions, e.g.
 {{{
   File "/django/tests/field_defaults/tests.py", line 175, in
 test_full_clean
 obj.full_clean()
   File "/django/django/db/models/base.py", line 1586, in full_clean
 self.clean_fields(exclude=exclude)
   File "/django/django/db/models/base.py", line 1641, in clean_fields
 setattr(self, f.attname, f.clean(raw_value, self))
   File "/django/django/db/models/fields/__init__.py", line 830, in clean
 value = self.to_python(value)
   File "/django/django/db/models/fields/__init__.py", line 1620, in
 to_python
 parsed = parse_datetime(value)
   File "/django/django/utils/dateparse.py", line 114, in parse_datetime
 return datetime.datetime.fromisoformat(value)
 TypeError: fromisoformat: argument must be str
 }}}
-- 
Ticket URL: 
Django 
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/0107018e18db1c76-82a9ef85-c4af-4b9a-bceb-9f07576958ba-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  Damir
 Type:   |  Nafikov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bcail):

 * has_patch:  0 => 1

Comment:

 I opened [https://github.com/django/django/pull/17939 a PR].
-- 
Ticket URL: 
Django 
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/0107018e10950b8b-becd65a0-d8d9-4a40-aee2-0c8d808b71ac-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  Damir
 Type:   |  Nafikov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bcail):

 * cc: bcail (added)

Comment:

 @Damir Nafikov, are you still working on this ticket?
-- 
Ticket URL: 
Django 
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/0107018e0a61050c-9078e13a-b335-44d4-9e67-3876dfa5ddfb-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  Damir
 Type:   |  Nafikov
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Damir Nafikov):

 * owner:  nobody => Damir Nafikov
 * status:  new => assigned

-- 
Ticket URL: 
Django 
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/0107018dcc44bd65-2135c6ae-056d-4983-8e4c-b88c512f111f-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
 Reporter:  Brian Ibbotson   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted
 * type:  Bug => Cleanup/optimization

Comment:

 Replying to [comment:4 Simon Charette]:
 > I believe that we should find a way to have `db_default` behave the same
 way as generated fields when no value has been assigned to the instance
 when `full_clean` is called (#35127). Requiring users to explicitly pass
 it to `exclude` is simply bad ergonomics IMO.

 Agreed, I think we should treat this as a cleanup not bug.
-- 
Ticket URL: 
Django 
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/0107018db8515e55-d755d226-4ccc-4873-b913-a4893179c607-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#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
-+-
Comment (by Simon Charette):

 I believe that we should find a way to have `db_default` behave the same
 way as generated fields when no value has been assigned to the instance
 when `full_clean` is called (#35127). Requiring users to explicitly pass
 it to `exclude` is simply bad ergonomics IMO.

 One thing that the solution should take into account is that the value
 should only be skipped when the value is not assigned. In other words

 {{{#!python
 class Article(models.Model):
upvotes = models.PositiveIntegerField(db_default=0)

 a1 = Article(upvotes=-1)
 a1.full_clean()  # should raise a ValidationError

 a2 = Article(upvotes=42)
 a2.full_clean()  # should *not* raise a ValidationError

 a1 = Article()
 a1.full_clean()  # should not raise a ValidationError
 }}}

 In other words, when a value is present it should be validated otherwise
 if `db_default` is provided it should be assumed to be valid just like
 it's the case with generated fields.

 A workaround in the mean time is to have both `default` and `db_default`
 assigned but obviously that kind of defeats the purpose of using
 `db_default` in the first place.
-- 
Ticket URL: 
Django 
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/0107018db3cd7f7b-4071fe8d-6aa8-454d-9e69-5fb99e577da8-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#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
-+-
Comment (by Mariusz Felisiak):

 > I would suggest having fields with db_default be excluded by default
 from full_clean()

 `db_default` is just a default value, we cannot always exclude it from
 `full_clean()`. What about not valid values provided explicitly in
 `create()`? What about `None` when field is non-nullable? etc.
-- 
Ticket URL: 
Django 
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/0107018db3cad4b7-8048c91f-722d-4ae9-8dfd-01bb422addd3-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#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: 
Django 
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-00%40eu-central-1.amazonses.com.

Re: [Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#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: 
Django 
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/0107018db3999ef9-c470e772-ef1c-4193-8bfb-f0c404a3d4c2-00%40eu-central-1.amazonses.com.

[Django] #35223: Fields with db_default raise ValidationErrors when full_clean() called

[Django]

#35223: Fields with db_default raise ValidationErrors when full_clean() called
-+-
   Reporter: |  Owner:  nobody
  quinceleaf |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  5.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 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: 
Django 
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/0107018db3986ec5-88665396-1fe9-4dbb-bb07-034612627f26-00%40eu-central-1.amazonses.com.