Re: Model-level validation

[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 models do not run 
something which is already internal to itself, i.e. they are not actually 
fully functional as a data store layer, unless an external thing 
(ModelForm) is implemented. That feels wrong to me.
On Friday, September 30, 2022 at 2:19:35 PM UTC-7 j.bre...@netzkolchose.de 
wrote:

> @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 
> and ponies with Django, but python-side data validation never crossed my 
> way as seriously flawed in Django. NOT EVEN ONCE. (Could list at least 
> 5-7 other topics that are somewhat tedious to get done with Django, but 
> thats offtopic here.)
>
> Plz dont jump from personal frustration about poor development processes 
> you have observed to all-conclusions, that depict most Django users as 
> total noobs. (Still funny to read, as it reminded me on those flaming 
> wars between Perl and Python folks ~18ys ago, which abruptly ended when 
> Perl6 finally made its debut.)
>
> > 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.
>
> I'm sorry if I didn't answer that more directly for you - nope, imho it 
> should not be done by default on `Model.save`. It violates the path in 
> separation of concerns Django has chosen with form validation, thus the 
> -1 from my side.
>
>
> Regards,
> Jörg
>

-- 
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/5faab961-7e4d-4714-aa78-f5fd2faa0212n%40googlegroups.com.

Re: Model-level validation

[Jörg Breitbart]

@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 
and ponies with Django, but python-side data validation never crossed my 
way as seriously flawed in Django. NOT EVEN ONCE. (Could list at least 
5-7 other topics that are somewhat tedious to get done with Django, but 
thats offtopic here.)


Plz dont jump from personal frustration about poor development processes 
you have observed to all-conclusions, that depict most Django users as 
total noobs. (Still funny to read, as it reminded me on those flaming 
wars between Perl and Python folks ~18ys ago, which abruptly ended when 
Perl6 finally made its debut.)


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

I'm sorry if I didn't answer that more directly for you - nope, imho it 
should not be done by default on `Model.save`. It violates the path in 
separation of concerns Django has chosen with form validation, thus the 
-1 from my side.



Regards,
Jörg

--
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/04eccdc2-d67d-2051-d0dd-a8749fb6b1a4%40netzkolchose.de.

Re: Model-level validation

[Aaron Smith]

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 fo

RE: Model-level validation

[Danilov Maxim]

I am completely agree with Jörg.

We use 
Model.full_clean
And 
Model.validate_unique to check conditional constraints.

It was more than enough. I've not seen any case - where I need something else. 


Mit freundlichen Grüßen,
DI Mag. Maxim Danilov

+43(681)207 447 76
ma...@wpsoft.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 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,
>   

Re: Model-level validation

[Jörg Breitbart]

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_ bee

Re: Proposal: Add utility class "ClassList"

[Jacob Rief]

Hey Carlton,
in my opinion, the main use case would be to improve type safety, 
readability and to add a
utility class for 3rd party packages. Someday, Django may add type hints 
and then this would
be really beneficial.

In Django itself, the mentioned method css_classes 

 does 
not offer any type safety;
the passed in argument extra_classes can be None, a string containing a 
single
CSS class or list containing those classes.

By adding such a utility class, we can rewrite the above method to

css_classes(extra_classes: ClassList):
# optionally: extra_classes = ClassList(extra_classes)
extra_classes.toggle(getattr(self.form, "error_css_class", None), 
self.errors)
extra_classes.toggle(getattr(self.form, "required_css_class", None), 
self.field.required)
return extra_classes

which is much easier to read.

In my project django-formset , I 
was able to remove a lot of boilerplate, by introducing that class.

Naming that Python class ClassSet or CSSClassSet or CSSClasses might be a 
better option.
I used ClassList because that's the name in JavaScript.

– Jacob  


On Thursday, September 29, 2022 at 9:35:02 AM UTC+1 Carlton Gibson wrote:

> Hey Jacob. Thanks for this. 
>
> Can I ask you to give a few examples of potential usages in Django, and 
> showing the gain over use a set in these cases? 
>
> I'm trying to imagine exactly what you have in mind, but I'm not entirely 
> clear. 
>
> Thanks again. 
> Carlton
>
> On Friday, 23 September 2022 at 11:14:27 UTC+2 Jacob Rief wrote:
>
>> In JavaScript each HTMLElement has a property named classList 
>> . 
>> This actually is a set allowing to *add* a single CSS class string, 
>> *remove* it
>> and/or *toggle* it.
>>
>> If we would reimplement this as a Python class, methods such as
>> css_classes 
>> 
>>  
>> could be implemented as a one-liner. This would also be beneficial
>> for future uses of similar methods in Django and 3rd party libraries, 
>> because it is a quite
>> common use case that one has to change the list of CSS classes as an 
>> element
>> attribute.
>>
>> – Jacob
>>
>

-- 
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/6d01cf69-23eb-4e8a-a13e-b29f26deab7an%40googlegroups.com.

Re: Proposal: cacheif template tag

[Carlton Gibson]

Hey Igor,

I wonder if you can achieve the same varying the timeout parameter based in
user.is_authenticated?

Kind Regards,

Carlton

On Sat, 24 Sept 2022 at 15:35, Igor Margitich  wrote:

> Hi django-developers,
>
> I would like to propose new template tag `cacheif`. Could be useful when
> you need to cache part of html and it depends on some condition. Template
> tag is similar to built-in `cache` tag but accepts extra boolean parameter.
> See example:
>
> {% cacheif user.is_anonymous 10 homepage %}
>   
>  .
>   
> {% endcacheif %}
>
>
> --
> 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/bcf8ffee-6497-4a55-ba40-913446d15b06n%40googlegroups.com
> 
> .
>

-- 
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/CAJwKpyS%3DYeGUCnbOr47BfU5SDKdCs83%3DvULAMa2E2rmPvNZBig%40mail.gmail.com.