#13776 closed Bug (fixed)
is_valid() with null field value on ModelForms from models with non-nullable ForeignKeys causes ValueError
Reported by: | Peter Bengtsson | Owned by: | ANUBHAV JOSHI |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Normal | Keywords: | ModelForm ForeignKey |
Cc: | Roman Barczyński, Mjumbe Poe, anubhav9042@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
See this email for a longer description and a traceback.
In summary:
If you try to use a ModelForm to create a form without the intention of running the save()
method it will raise a ValueError when you call is_valid()
. This is because the ForeignKey field has a setattr override which prevents it from being None at all, ever. When you're just testing the form it should wrap this in a case so that it doesn't immediately complain.
Attachments (1)
Change History (24)
comment:1 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 14 years ago
comment:3 by , 14 years ago
Summary: | is_valid() on ModelForms on models with ForeignKeys cause ValueError rather than False → is_valid() with null field value on ModelForms from models with non-nullable ForeignKeys causes ValueError |
---|---|
Triage Stage: | Accepted → Design decision needed |
In #6886 with r8185 we introduced the requirement for the reverse descriptor that null and wrong-model assignments to ForeignKey fields would be disallowed prior to save-time. In r12098 with the model-validation merge, we changed the operation of ModelForms to construct instances at validation time, not at save-time. The combination of these two limits the developer's ability to preeempt the automated validation with ForeignKeys. For another example, see this other thread - a user's model populates a non-nullable FK with an overridden save method which would satisfy the not-null requirement, but the ModelForm created by the admin throws an error before save-time.
This requires some core developer time to figure out how to proceed.
comment:4 by , 14 years ago
Cc: | added |
---|
comment:5 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → Bug |
comment:9 by , 12 years ago
Triage Stage: | Design decision needed → Accepted |
---|
comment:10 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:11 by , 11 years ago
Cc: | added |
---|
comment:12 by , 11 years ago
Owner: | changed from | to
---|
comment:13 by , 11 years ago
Currently if blank=True and null is not True, ValueError is raised. The check being in related.py line 399 for ForeignKey.
a.) I think we can display a correct message depicting the problem that in ForeignKey with null=True can only be left blank.
b.) We can stop the usage of blank=True with ForeignKey, because alone without null=True defined it has no significance and give suitable error message instead of raising an error. null=True alone works perfectly
Any opinions?
comment:14 by , 11 years ago
Cc: | added |
---|
follow-up: 17 comment:16 by , 11 years ago
I think blank=True
with null=False
is acceptable. For example, you might fill in the value of the ForeignKey
in the object's save()
method.
comment:17 by , 11 years ago
Replying to timo:
I think
blank=True
withnull=False
is acceptable. For example, you might fill in the value of theForeignKey
in the object'ssave()
method.
What about is_valid
in case of ModelForm?
comment:18 by , 11 years ago
We should try to fix it so that an exception is not raised. As noted in the django-users thread, the use-case worked in Django 1.0, but broke in 1.2.
by , 11 years ago
Attachment: | 13776.diff added |
---|
comment:19 by , 11 years ago
Has patch: | set |
---|---|
Version: | 1.2 → master |
comment:20 by , 11 years ago
As discussed on IRC, the patch isn't what we want. There shouldn't be a form error because the form is valid according to its specification.
comment:21 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Another scenario reported here: http://groups.google.com/group/django-users/browse_thread/thread/8ea803cb8a28e594#