I am completely agree with Jörg.
We use
Model.full_clean
And
Model.validate_unique to check conditional constraints.
It was more than enough. I've not seen any case - where I need something else.
Mit freundlichen Grüßen,
DI Mag. Maxim Danilov
+43(681)207 447 76
ma...@wpsoft.at
-----Original Message-----
From: django-developers@googlegroups.com
[mailto:django-developers@googlegroups.com] On Behalf Of Jorg Breitbart
Sent: Friday, September 30, 2022 10:12 AM
To: django-developers@googlegroups.com
Subject: Re: Model-level validation
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.
--
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/000001d8d4a7%24e6dcda10%24b4968e30%24%40wpsoft.at.
