Fields with db_default raise ValidationErrors when full_clean() called

[Brian Ibbotson]

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.