Why does ModelForm do validation and not Model

[Will Gordon]

I can't seem to find a good reason for this. And I could foresee this preventing potential mistakes. I'm not proposing to actually change the implementation, I guess I'm just looking for the reason of it.

[Aymeric Augustin]

Hello Will,

It's mostly for performance reasons, since validation can be expensive. You can override save() to call full_clean() in a model if you'd like.

Cheers,

-- 

Aymeric.

On 16 Apr 2019, at 20:47, Will Gordon <wpg...@gmail.com> wrote:

I can't seem to find a good reason for this. And I could foresee this preventing potential mistakes. I'm not proposing to actually change the implementation, I guess I'm just looking for the reason of it.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/97ae2f12-bc27-403d-8b76-f456a63fc0d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Will Gordon]

So the validation is cheaper when performed by ModelForm, as opposed to the Model?

[Tom Forbes]

The idea is that you generally always have to do extensive validation when accepting user input through a form. These validations could require additional database queries or other somewhat expensive lookups (especially with validate unique).

However if you are loading data from a trusted source, e.g:

for row in your_csv_file:
    instance = Model(**row)
    instance.save()  

Then there is no need to call that potentially slow full_clean(). There is not much value in slowing down all .save()’s needlessly - the developer should know when it’s appropriate to run validations and can run full_clean() when needed.

On 16 April 2019 at 21:42:24, Will Gordon (wpg...@gmail.com) wrote:

So the validation is cheaper when performed by ModelForm, as opposed to the Model?

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8d929b8e-b0e9-4a88-b796-26f00266f729%40googlegroups.com.

[Will Gordon]

Ahh, cool. That makes more sense. I worry that it still leaves open the potential of accidentally not validating something. It may make more sense to offer instance.save(validate=False) instead of relying on the developer to always know whether they can trust the input. But I agree that for historical reasons, I'm sure it's much more difficult to implement this now.

[Curtis Maloney]

On 4/17/19 4:55 AM, Aymeric Augustin wrote:
> Hello Will,
>
> It's mostly for performance reasons, since validation can be expensive.

Really? My memory was that it was (a) backward compatibility [model
validation was added later], and (b) practicality [try catching
everywhere in your code you save a model, and enforce catching
validation exceptions there].

Models _support_ validation, but don't _enforce_ it.

--
Curtis

[Aymeric Augustin]

Hi Curtis,

Le mer. 17 avr. 2019 à 22:32, Curtis Maloney <cur...@tinbrain.net> a écrit :

> It's mostly for performance reasons, since validation can be expensive.

Really? My memory was that it was (a) backward compatibility [model
validation was added later], and (b) practicality [try catching
everywhere in your code you save a model, and enforce catching
validation exceptions there].

These arguments are absolutely valid.

I can't say for sure if some concerns ranked higher than others.

 

--

Aymeric.

[Václav Řehák]

Dne čtvrtek 18. dubna 2019 10:56:55 UTC+2 Aymeric Augustin napsal(a):

The question is if there is consensus that model validation should really be opt-in.

 As a veteran Django user, I am quite used to it but as I work on financial project (with strong requirements on data consistency) with a team of senior developers kind of new to Django I face a lot of confusion about why does Django let us save invalid data (actually last week I spent almost 3 days on fixes caused forgotten calls to full_clean and on data migration to clean up the mess). If it was possible, e.g. in settings, to force model validation in save(), it would help us a lot.

Vaclav

[Tobias Kunze]

On 19-04-18 05:07:53, Václav Řehák wrote:
>If it was possible, e.g. in settings, to force model
>validation in save(), it would help us a lot.

Would it help you even if this would only apply to actual `save()`
calls, no bulk creates, no bulk updates, and no modifications of
m2m relationships via add/remove? I'm not sure if "forced validation …
on some cases" wouldn't be even more confusing in those tricky cases.

Tobias

[René Fleschenberg]

Hi

On 4/18/19 2:07 PM, Václav Řehák wrote:
>  As a veteran Django user, I am quite used to it but as I work on
> financial project (with strong requirements on data consistency) with a
> team of senior developers kind of new to Django I face a lot of
> confusion about why does Django let us save invalid data (actually last
> week I spent almost 3 days on fixes caused forgotten calls to full_clean
> and on data migration to clean up the mess). If it was possible, e.g. in
> settings, to force model validation in save(), it would help us a lot.

You can make an abstract model with an overriden save() that calls
full_clean() and inherit all your models from it. However, remember that
this does not cover all database writes. For example, update() on a
queryset does not call save(). For this reason, I don't think it is a
good idea. It just gives developers a false sense of security. Instead,
make sure to validate all input at the application boundary (e.g. using
forms).

If data integrity is really important, also consider using
database-level constraints. This can be done using raw SQL from a
migration. In Django 2.2, there also is
https://docs.djangoproject.com/en/2.2/ref/models/constraints/.


--
René Fleschenberg