,
> 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's concern, then get
>>>
appen 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 in long enough now that it
would be very difficult to
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
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 wish model-leve
>
> 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 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
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
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
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
> 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
ppens *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
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 even as an
> option, because i
אורי
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
> ... 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
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
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
e 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 e
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.
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 even as an
option, because in a web framew
אורי
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
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
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
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
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
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
@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
datedModel), 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 i
-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 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
>> 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 answ
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: back
>> 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
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
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, with Djan
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_ b
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
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
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
אורי
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
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
42 matches
Mail list logo
