Re: Model-level validation

turn it off and do it the 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

Re: Model-level validation

> > 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 on

Re: Model-level validation

e pattern. On Friday, 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

Re: Model-level validation

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 timer

Re: Model-level validation

>> >> Perhaps we think about validation differently. I consider it to be >> critical to maintain complex systems with any kind of confidence, any time >> data is being created or changed, regardless of where that change comes >> from. Bugs can happen anywhere and val

Re: Model-level validation

at 12:03:28 PM 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 y

Re: Model-level validation

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 divergen

Re: Model-level validation

speedy.net > > > 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 `sa

Re: Model-level validation

pport 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 Dj

Re: Model-level validation

exists in the TextChoices `values` 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

Re: Model-level validation

cult to work with, >> understand, and maintain. >> >> 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, Sept

Re: Model-level validation

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 model

Re: Model-level validation

dModel` 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

Re: Model-level validation

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`

Re: Model-level validation

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

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 lev

Re: Model-level validation

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 hi

Model-level validation

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 conc

Re: Model-level validation

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 m