Jorg, My observations come from the real world and are not hypothetical guesses. Among the dozen of Django applications I have worked on, at 3 companies, not a single one was actually running any kind of validation. It has always been a mistake, 100% of the time, *never* the desired behavior.
Django applications are usually worked on by people who are pressed into service to work on a web app because they know python. Most are not professional coders. They do the easiest possible thing and read a minimum of documentation. As a result, they wind up with horrible data consistency problems that they need to hire people like me to clean up. The question is not whether you *can* compose validation into django models. The concern is that it should be done *by default* to protect the average naive newbie developer from mistakes. On Friday, September 30, 2022 at 1:12:18 AM UTC-7 j.bre...@netzkolchose.de wrote: > 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-develop...@googlegroups.com > > <mailto:django-develop...@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/726124ce-4aad-402e-89fb-e22b9f122215n%40googlegroups.com.
