#29549: Model.save() doesn't validate CHOICES
-------------------------------------+-------------------------------------
Reporter: Evgeny Arshinov | Owner: nobody
Type: Uncategorized | Status: new
Component: Database layer | Version: 1.11
(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
-------------------------------------+-------------------------------------
Old description:
> This is basically a sequel of #6967.
>
> For some reason, only form validation was considered in the original
> ticket, but data validation is not limited to that, but also includes
> data integrity checks running when one calls `model_instance.save()`.
>
> As a developer, I would expect `model_instance.save()` to validate the
> `choices` field against the list of possible choices, not least because
> the list is defined at the model level, participates in db migrations
> etc., so it should take effect on modal instances.
>
> I haven't been able to find any documentation or existing bug reports
> that clearly state that [choices
> https://docs.djangoproject.com/en/2.0/ref/models/fields/#choices]
> argument only affects the corresponding model form field presentation and
> does not ensure data integrity.
>
> In summary:
> 1. I would like to know the rationale for ignoring `choices` during data
> integrity checks, in case I am missing something.
> 2. Please consider providing an option to turn data integrity check on.
> 3. If the current behavior is left intact, it should be explicitly
> documented in the official documentation.
New description:
This is basically a sequel of #6967.
For some reason, only form validation was considered in the original
ticket, but data validation is not limited to that, but also includes data
integrity checks running when one calls `model_instance.save()`.
As a developer, I would expect `model_instance.save()` to validate the
`choices` field against the list of possible choices, not least because
the list is defined at the model level, participates in db migrations
etc., so it should take effect on modal instances.
I haven't been able to find any documentation or existing bug reports that
clearly state that
[https://docs.djangoproject.com/en/2.0/ref/models/fields/#choices choices]
argument only affects the corresponding model form field presentation and
does not ensure data integrity.
In summary:
1. I would like to know the rationale for ignoring `choices` during data
integrity checks, in case I am missing something.
2. Please consider providing an option to turn data integrity check on.
3. If the current behavior is left intact, it should be explicitly
documented in the official documentation.
--
Comment (by Evgeny Arshinov):
Replying to [comment:1 Tim Graham]:
> Did you mean to title the ticket "Model.save() doesn't validate
CHOICES"?
>
Yes. Sorry for the incorrect title, I fixed that.
> This is
[https://docs.djangoproject.com/en/dev/ref/models/instances/#django.db.models.Model.clean
documented]:
>
> > Note, however, that like Model.full_clean(), a model’s clean() method
is not invoked when you call your model’s save() method.
OK, I think I did not pay enough attention to the point that saving and
validation are two different steps, as documented in the
[https://docs.djangoproject.com/en/dev/ref/models/instances/#validating-
objects model instance reference], and fields are generally validated
during `clean()` except for explicitly documented cases like
[https://docs.djangoproject.com/en/2.0/ref/models/fields/#unique unique]
(which is validated in `save()`).
However, it seems that many people stumble upon this issue. Maybe an
explicit note could be added to the documentation for the choices
parameter?
>
> This is because of backwards compatibility (and probably performance
considerations).
>
> There are ways to [https://stackoverflow.com/questions/4441539/why-
doesnt-djangos-model-save-call-full-cleanchange change the behavior in
your project].
OK, thank you for the direct link. We will consider using this approach in
our project.
--
Ticket URL: <https://code.djangoproject.com/ticket/29549#comment:2>
Django <https://code.djangoproject.com/>
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.2dbd776c84183fe84eea4b2a007f88b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
