win for us.
>
> LP,
> Jure
> On 9. 10. 22 08:58, James Bennett wrote:
>
> On Sat, Oct 8, 2022 at 8:32 PM Aaron Smith wrote:
>
>> Surely we can agree that *something* should happen here? The status quo
>>> is confusing, a footgun and a gotcha. If it's not Model
/something/ should happen here? The
status quo is confusing, a footgun and a gotcha. If it's not
Model's concern, then get it out of Model.
I've already said that I wish model-level validation hadn't been added
to Django.
Unfortunately it's something that's been
I see two separate concerns here:
1) Should Django present to users the option to do validate-on-save by
default? That is, should that option be visible -- in the form of a
documented setting or an optional argument to save()?
I tend to accept James' (and others) views and reasoning against that
On Sat, Oct 8, 2022 at 8:32 PM Aaron Smith wrote:
> Surely we can agree that *something* should happen here? The status quo
>> is confusing, a footgun and a gotcha. If it's not Model's concern, then get
>> it out of Model.
>>
>
I've already said that I
>
> 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
On Sat, Oct 8, 2022 at 8:44 AM Aaron Smith wrote:
> The reason I don't want to use serializers or forms in celery tasks is
> because validation should happen every time a model attribute is changed.
> This pattern would mean more imports and boilerplate scattered around my
> codebase any time I w
James - these developers come from all over. They represent the random
sample of people who end of working on or inheriting legacy django
projects. Probably more Rails than anything else, but a few who probably
worked with Hibernate or Node frameworks. For better or worse, it's who's
using djan
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
> developer (dozens) I've had this conversation with up until now. It's a
> stark contrast that m
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
> I am aware there are patterns to work around this in Django. My position
is that skipping validation should be the rare edge case and not the easy
naive path. Unless Django's stated purpose is to be a cute toy for making
blogs, and robust infrastructure is off-label, but that's not what I see
s *all the time*.
Nothing is more dangerous than a developer who says "don't worry, I'll
remember to do everything perfectly 100% of the time". This is why
model-level validation is the default in other ORMs. Django is not somehow
immune to this fundamental property of s
to do your
> data conversion and validation in the ORM layer if you want to. But Django
> is, first and foremost, a web framework, which needs to support the web use
> case I've described above, and so its primary conversion/validation layer
> can never be the ORM.
>
> Personally,
אורי
u...@speedy.net
On Fri, Oct 7, 2022 at 10:01 AM Carlton Gibson
wrote:
> > ... the duplication I was referring to is having both Forms and
> Serializers do validation.
>
> That's a separate issue.
>
> Can we merge various aspects of DRF into Django, so that it better handles
> building JSON
> ... the duplication I was referring to is having both Forms and
Serializers do validation.
That's a separate issue.
Can we merge various aspects of DRF into Django, so that it better handles
building JSON APIs? Yes, clearly. One step of that is better content type
handling, another is serialize
James - to clarify, the duplication I was referring to is having both Forms
and Serializers do validation. I often work with web apps where data for
the same model can arrive via user input, serializer, or created in some
backend process e.g. Celery. If forms/serializers are your validation
lay
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 comes from multiple sources or domains (web
> forms *and* API endpoints
ata conversion and validation in the ORM layer if you want to. But Django
> is, first and foremost, a web framework, which needs to support the web use
> case I've described above, and so its primary conversion/validation layer
> can never be the ORM.
>
> Personally, I wish model
Uri - that's a great upgrade path (or should I say, non-upgrade path).
Agree with `VALIDATE_MODELS_BY_DEFAULT`.
Rails also skips validations for some operations, like `update_column`, but
they are prominently marked to use with caution, and the other ORMs i've
used follow a similar pattern. bul
validation in the ORM layer if you want to. But Django
is, first and foremost, a web framework, which needs to support the web use
case I've described above, and so its primary conversion/validation layer
can never be the ORM.
Personally, I wish model-level validation had never been added ev
אורי
u...@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 `save()`, defaulted to `False`. This maintains
FWIW +1 from me!
--
C
On Thu, 6 Oct 2022, at 14:11, 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 `False`. This maintain
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 `False`. This maintains
backwards compatibility and also moves the validation behavior users coming
to
David -
All of your points are accurate. A usable ORM will probably never be
perfectly safe, and none of the Django workarounds are particularly
difficult. But requiring extra steps to get the save level of data safety
as other ORMs will, just by nature of human nature and scale, make Django a
I'm glad you brought up tests, because automated tests for these issues are
quite difficult and require tribal knowledge. A first-hand example from a
while back: The application had over 90% test coverage, including all of
the validation rules in the DRF serializer. One of those rules was that a
I'm not really interested in debating whether the ORM validates or not but
I thought it might be worth pointing out a few things that haven't been
touched on yet:
> It's not right.
Design decisions are often neither outright right nor wrong but more
tradeoffs of varying values.
> The data store
> 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.
Besides not taking time to understand how Django works, it seems they
weren't do
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
@Aaron
Oh well, if anecdotal personal evidence counts for you - here is mine:
Working here since 2008 with Django in tons of projects in different
positions. The project sizes were from small websites to big API-driven
SPA cluster installations (with and w'o DRF). Ofc it is not all rainbows
a
es
> > (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 m
ft.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 wher
lidate 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 poss
bases.
>>
>> 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()?
>>>
>>>
>>>
tion 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:
>> 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 i
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
On Thu, Sep 29, 2022 at 6:19 PM Curtis Maloney 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,
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 _
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
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
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
אורי
u...@speedy.net
On Thu, Sep 29, 2022 at 11:04 AM Carlton Gibson
wrote:
>
> On Thursday, 29 September 2022 at 06:29:30 UTC+2 aa...@aaronsmith.co
> wrote:
>
>> Why doesn't Django validate Models on save()?
>>
>> I am aware that full_clean() is called when using ModelForms. But most
>> web ap
Hi.
I have to ask, did you search the history at all here? This has been
discussed *several times* over the years.
> Bringing View-level concepts such as forms down into celery tasks and
management commands breaks separation of concerns...
I think it's an error to think of forms (please read
42 matches
Mail list logo
