Re: Model-level validation

2022-10-12 Thread Aaron Smith
e way you believe is "the correct one". > > Also, just to be clear: the above solution (turning this on) yielded TONS > of bugs when we did it for our projects. We vastly improved unit testing > following this implementation, so it was a total win for us. > > LP

Re: Model-level validation

2022-10-08 Thread Aaron Smith
> > And so I am still very strongly against trying to push a > model-layer-validation approach in Django, even optionally. > It already exists, though. `full_clean()` is a method on Model. CharFields on the model *already* have a notion of allowed choices. Validators are *already* an option

Re: Model-level validation

2022-10-08 Thread Aaron Smith
, October 7, 2022 at 11:28:58 PM UTC-7 James Bennett wrote: > On Fri, Oct 7, 2022 at 6:21 PM Aaron Smith wrote: > >> Mariusz - fair enough, I will consider my point made and apologies if it >> came off too strong. FWIW it's not just my opinion, it's shared by every >> dev

Re: Model-level validation

2022-10-07 Thread Aaron Smith
Mariusz - fair enough, I will consider my point made and apologies if it came off too strong. FWIW it's not just my opinion, it's shared by every developer (dozens) I've had this conversation with up until now. It's a stark contrast that makes me wonder how aware the core developers / old

Re: Model-level validation

2022-10-07 Thread Aaron Smith
to `validate` kwarg to `save()` — that's every user ever > wondering *should I use it? *every time. (Same for a setting.) > Rather — is this a docs issue? — we should re-emphasise the importance of > the validation layer. > Then if folks want a convenience API to do both tasks, they're

Re: Model-level validation

2022-10-06 Thread Aaron Smith
UTC-7 James Bennett wrote: > On Thu, Oct 6, 2022 at 9:00 AM Aaron Smith wrote: > >> James - The problem with moving validation up the stack, i.e. to logical >> branches from Model (Form, Serializer) is that you must duplicate >> validation logic if your data com

Re: Model-level validation

2022-10-06 Thread Aaron Smith
James - The problem with moving validation up the stack, i.e. to logical branches from Model (Form, Serializer) is that you must duplicate validation logic if your data comes from multiple sources or domains (web forms *and* API endpoints *and* CSVs polled from S3. Duplication leads to

Re: Model-level validation

2022-10-06 Thread Aaron Smith
gt; > On Thu, Oct 6, 2022 at 6:11 AM Aaron Smith wrote: > >> It sounds like there is little support for this being the default. But >> I'd like to propose something that might satisfy the different concerns: >> >> 1) A `validate` kwarg for `save()`, defaulted to `Fals

Re: Model-level validation

2022-10-05 Thread Aaron Smith
the status quo, but in my personal experience, having had this conversation with dozens of coworkers over the years - 100% of them expressed a strong desire for Django to do this differently. On Wednesday, September 28, 2022 at 9:29:30 PM UTC-7 Aaron Smith wrote: > Why doesn't Django valid

Re: Model-level validation

2022-10-01 Thread Aaron Smith
` attribute. >- Validation of non-overlapping date ranges? Use range types with >exclusion constraints. >- Only 1 column from a set of columns should be set? Use a check >constraint with an xor not null test. >- There are plenty more of these :) > > Only the

Re: Model-level validation

2022-10-01 Thread Aaron Smith
; >> If Forms were truly the validation layer, why am I able to specify things >> like maximum length and allowed choices on the Model? Shouldn't those >> things be specified at the Form layer? >> On Friday, September 30, 2022 at 4:27:13 PM UTC-7 Aaron Smith wrote: >> >>

Re: Model-level validation

2022-09-30 Thread Aaron Smith
Jorg, I do not believe it violates any separation of concerns. `full_clean()` is already a method on the Model class itself. The Model is already where all validation logic lives, except for the actual *triggering* of the validation. What I believe violates separation of concerns is that

Re: Model-level validation

2022-09-30 Thread Aaron Smith
ed 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

Re: Model-level validation

2022-09-29 Thread Aaron Smith
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 `Mo

Re: Model-level validation

2022-09-29 Thread Aaron Smith
have been there for some of it - data consistency problems are horrible. On Thursday, September 29, 2022 at 5:36:29 PM UTC-7 carl.j...@gmail.com wrote: > On Thu, Sep 29, 2022 at 6:19 PM Curtis Maloney > wrote: > >> On Thu, 29 Sep 2022, at 14:29, Aaron Smith wrote: >>

Re: Model-level validation

2022-09-29 Thread Aaron Smith
ion 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 va

Re: Model-level validation

2022-09-29 Thread Aaron Smith
Yes, I did search, and I did not find an answer to my question. If one is always supposed to use a ModelForm, why isn't that ModelForm functionality part of the Model? On Thursday, September 29, 2022 at 1:04:17 AM UTC-7 carlton...@gmail.com wrote: > Hi. > > I have to ask, did you search the

Model-level validation

2022-09-29 Thread Aaron Smith
Why doesn't Django validate Models on save()? I am aware that full_clean() is called when using ModelForms. But most web app development these days, and every django app I've ever worked with, are headless APIs. The default behavior is dangerous for the naive developer. Bringing View-level

Re: Model-level validation

2022-09-29 Thread Aaron Smith
All I was able to find was that it was for "performance reasons", and I refuse to believe that a mature web framework like Django would prioritize performance (let's face it - even my millions-of-requests-per-day API service doesn't care about a few extra milliseconds here and there) over the