Hi there,
I dont quite understand where the sudden fuzz about this comes from. I
want to point out a few things, before going down the rabbit hole of
competing high level interfaces, that ValidatedModel/UnvalidatedModel
would introduce:
- Django offers all validation needs as building blocks. It is literally
a Mixin away, where you can create a validate_and_save method yourself,
pulling in any level of validation you need. Thats most flexible and has
always covered our needs (up to validate complex side constraints, that
dont fit the default validators).
- The ORM is still a quite thin abstraction on top of the db engines,
which is good as it keeps things speedy. In terms of isolation of
concerns this is again just a db building block, thus I'd expect
`Model.save` to do the db work persistence work, not any other side
tracking work. Also `save` already is quite fat (a reason why we often
reshape things to use batch/bulk actions and do validation quite different).
- Validation on `save` might not be wanted for different reasons (e.g.
data got already validated by other means).
- Because other frameworks always validate data itself before writing to
database is a no-argument - it is clearly stated in the docs, that
`save` does *not* do it (maybe needs more prominent mentioning in
starter examples?) Or to make this as no-argument more blatantly: "Why
doesn't Python use curly braces, I've seen that in other languages, imho
it is a must-have!" - Nope its not. If in doubt - read the docs.
Now regarding another model interface doing validation on `save` - imho
this just creates more ambiguity for starters. Clearly bulk actions
cannot be treated that way - so now we have a model type that does
validation on `save` but not on any other bulk action. Great - ppl get
lured into thinking, that their data gets always validated not getting
the bulk catch.
Imho the opposite is easier to communicate even to starters - "Nope,
model actions dont do any data validation beside db-level integrity
checks. But the model type offers validation building blocks as of
`clean()`, `full_clean()` ... If you want explicit data validation do
this ... or that ..." (Note thats literally one Model.full_clean call
away if you are cool with djangos default validation ideas)
This gets a -1 from me for:
- mixing db concerns with python-side data validation
- and putting more work on `save`
Regards,
Jörg
Am 30.09.22 um 06:38 schrieb Adrian Torres:
Hi,
Regardless of what you consider ModelForms to be, the fact that
validation doesn't happen at the model level is very jarring if you've
ever used any other MVC framework, it was and still is one of the major
pet peeves of Django for me, to the point where we do something similar
to what Uri does, and I'm sure many other people do.
bulk_update is not an excuse, as Aaron mentioned many other ORMs /
frameworks come with features that forego certain safeties in favor of
performance / convenience, heck you can write SQL directly if you so
desire but you need to be ready to face the consequences.
I like the `UnvalidatedModel` vs `Model` idea proposed by Aaron.
Cheers,
Adrian
On Friday, September 30, 2022 at 3:39:20 AM UTC+2 aa...@aaronsmith.co wrote:
I would also like everyone to know, my objective in starting this
thread is to get the go-ahead to open a PR for this. I would like to
contribute back.
On Thursday, September 29, 2022 at 6:30:32 PM UTC-7 Aaron Smith wrote:
How about a new class, `ValidatedModel`, that subclasses `Model`
and does nothing more than call `full_clean()` on `save()`?
This would be completely backwards compatible, would clearly
communicate what it does, and when documented right next to
`Model` make it fairly obvious that Model is something other
than validated, hopefully preventing many footguns.
Or, and I think this would be better, if the current Model were
renamed `UnvalidatedModel`, the new validated implementation
above were `Model`. This upgrade path is a simple string
replacement for those legacy codebases
(Model->UnvalidatedModel), making it abundantly clear they are
not validated, and new apps following the most naive path
(Model) are as safe as possible. The new, validated,
`Model.save()` could accept the kwarg `validate=False` as an
opt-out, which as much as I hate to admit it is an important
option for some codebases.
On Thursday, September 29, 2022 at 5:19:07 PM UTC-7
cur...@tinbrain.net wrote:
On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote:
Why doesn't Django validate Models on save()?
The short answer is: backwards compatibility.
Model level validation hasn't always been a thing, with
Django initially depending primarily on Form validation.
Since it hadn't _always_ been there, it wasn't possible to
introduce it, enforce it, and not break most apps out there.
There was so much code written that generally assumed it
could call `save()` and not have to catch validation errors.
For what it's worth, I'm all in favor of making it run on
`save()` ... updating the documentation and preparing the
community is going to be a mammoth task, however. A safe
course through this will take some very careful planning.
--
C
--
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-developers+unsubscr...@googlegroups.com
<mailto:django-developers+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f51db24d-7c69-49f2-ad83-c8fd2418bfbdn%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/f51db24d-7c69-49f2-ad83-c8fd2418bfbdn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/74abdaee-fcb6-872d-25ad-545bbf9c9e3b%40netzkolchose.de.
