id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
35223	Fields with db_default raise ValidationErrors when full_clean() called	Brian Ibbotson	nobody	"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.

"	Bug	new	Database layer (models, ORM)	5.0	Normal			Brian Ibbotson	Unreviewed	0	0	0	0	0	0