Raise a check error if null=False and default=None

[Csirmaz Bendegúz]

If a field has null=False Django shouldn't allow setting default=None or db_default=None.

class Model(models.Model):
    text = models.TextField(default=None)

This will raise an IntegrityError on create.
It could be prevented with a system check.
Same applies to db_default.

[Csirmaz Bendegúz]

I think this is an easy win if someone else wants to work on it?

[Sarah Boyce]

For context, this has come up from ​this PR discussion

[Jacob Walls]

I'm not sure how we could do this, since requiring python-level defaults on model fields would break the pattern of defaulting fields empty but ​supplying missing values during validation.

More thorough discussion here:
​https://groups.google.com/g/django-developers/c/GlYM25fdRnA/m/wAimd4QPAwAJ

Happy to discuss further on the forum where more folks can contribute ideas.

[Csirmaz Bendegúz]

I'm not sure what you mean by requiring python-level defaults? To have default=None on a non-nullable field is a misconfiguration and we can easily add a ​system check to Field.check to prevent it? I'm sorry maybe I'm missing something

[Jacob Walls]

My point was that we if we permit blank=True for non-nullable fields (see linked discussions) then we should treat default=None no differently. It doesn't seem like a misconfiguration to me. The default kwarg on model fields is only one of several ways of accepting values before saving a non-nullable field to the database--we shouldn't force people to choose model field defaults as a way of supplying missing values.

If part of the proposal was to use a NOT_PROVIDED sentinel for the default value of default= so that explicitly providing Field(default=None) can be distinguished from Field() and flagged, then that's a different story, but I'm not sure it's worth it and would still break existing code.

[Jacob Walls]

My apologies for confusing things a little bit here.

If part of the proposal was to use a NOT_PROVIDED sentinel for the default value of default=

Well that's exactly what Django does, don't know why I seemed to think this morning that wasn't the case 🤦‍ ️

With that confession out of the way, it still strikes me that this should be sounded out on the forum to move it forward. To me, requiring Field() over Field(default=None) feels like a code-style convention for a linter, not a misconfiguration for a system check. Asking developers to prefer one over the other requires knowing that there is a difference, namely the NOT_PROVIDED sentinel, which we would also need to document. I think teaching this to users could be avoided.

(I also noticed while grepping test models for default=None that was discussed in the context of a check on the postgres ArrayField and was ​rejected albeit without much discussion.)