So, validating and saving models instances in #Django. Shouldn't we just call Model.full_clean() from Model.save() as a default, and make it possible to skip with a skip_clean argument? Am I missing something? It feels like a big win and avoids the footgun aspect of forgetting to run full_clean.
=> More informations about this toot | More toots from valberg@social.data.coop
@valberg What about when you're using a queryset.only('field_a'), then call instance.save('update_fields=['field_a'])?
=> More informations about this toot | More toots from CodenameTim@fosstodon.org
@CodenameTim I guess that would have the same effect as providing skip_clean.
=> More informations about this toot | More toots from valberg@social.data.coop
@valberg YES PLEASE AND THANK YOU https://github.com/bornhack/bornhack-website/blob/master/src/utils/models.py#L37-L58
=> More informations about this toot | More toots from tykling@mastodon.social
@valberg it's a pretty heavy subject. But I think that default would be too much. Then you would create a new footgun that makes you code perform badly.. or unable to save things that need to be saved.
https://docs.djangoproject.com/en/5.1/ref/models/instances/#validating-objects
=> More informations about this toot | More toots from benjaoming@social.data.coop
@benjaoming @valberg I have accidently save()d invalid data soo many times, and I have barely ever been annoyed about this code https://github.com/bornhack/bornhack-website/blob/master/src/utils/models.py#L37-L58
This tells me that defaulting to validating on save() would be a big win. Easily worth any small annoyances for cases where validation then has to be disabled.
=> More informations about this toot | More toots from tykling@mastodon.social
@benjaoming I'm willing to pay a bit of overhead if it means that data being saved to the database has been validated. And in those instances where performance is of utter importance I'm OK with having to do optimisations.
=> More informations about this toot | More toots from valberg@social.data.coop
@valberg @benjaoming “Use the form layer”
=> More informations about this toot | More toots from carlton@fosstodon.org
@carlton @benjaoming If you remove all the "render this into a HTML form" stuff of "the form layer" and make it into a clean "validation layer", I would be inclined to agree. But then again, it is a lot of overhead for just calling .full_clean() followed by .save().
=> More informations about this toot | More toots from valberg@social.data.coop
@valberg @benjaoming So two points there:
The was an oldish thread on django-developers that went into all the back story here at length, if you like archeology!
=> More informations about this toot | More toots from carlton@fosstodon.org
@carlton @benjaoming Hmm, yeah I can try to ignore it, but somehow it is hard since I've learned to use forms first and foremost as a way to validate input from a HTML form. And the documentation talks about forms in that way.
Also, having to activate the form layer when I have clean methods right there on my model feels tedious.
I know I'm welcome to call it, the thing is that I (and other Django devs I know) forget. So having it as a default still makes sense to me.
=> More informations about this toot | More toots from valberg@social.data.coop
@valberg @benjaoming Yes! And that feeling has been had by lots of people over the years. So you’re not “wrong” — but that’s not how Django does it…
“…Validate data from an HTML form…” — that’s Django’s primary use-case. Django is a web framework after all 🥳
I’m old. I will throw EVERYTHING through a form (or formset). I want to know that it’s been properly validated, even if it’s supposedly “trusted” — Uh huh, that CVS is valid you say?
=> More informations about this toot | More toots from carlton@fosstodon.org
@carlton @benjaoming But it could become how Django does it if it makes sense 😀
Yeah touché 😆 I just wish the validation part was separated so I could use that for my APIs and the HTML parts for my HTML views.
Do you then never add validation logic to the .clean() method of Model? Where is the locality of behaviour in all of this 😜
=> More informations about this toot | More toots from valberg@social.data.coop
@valberg @benjaoming It doesn’t make sense. 😅
Form jockey’s like me don’t want to move the responsibility to Model.save(). ORM heads don’t want the overhead without explicit opt-in. And so on… — there are reasons.
Maybe Django could have, once upon a time, have done something different here, but changing? No, not that.
…
=> More informations about this toot | More toots from carlton@fosstodon.org
@valberg @benjaoming I write a LOT of Form.clean() methods. I write a lot of Manager methods that encapsulate (and enforce) business rules. I don’t often override Model.clean or Model.save. I know other folks do more of that.
=> More informations about this toot | More toots from carlton@fosstodon.org
@carlton @valberg For me, that choice is often (not always) easy because of - if I may - 🌟 Locality of Behavior 🌟 of the validation errors messages.
Those messages mostly belong in the UI. So I find it easier to validate "close to the UI".
Edit: Oh, you've already played that card 😂
=> More informations about this toot | More toots from benjaoming@social.data.coop
@benjaoming @valberg That's a big one for me. If I have a form error, I can re-present the UI, and say, Try again.
=> More informations about this toot | More toots from carlton@fosstodon.org
@carlton @benjaoming Yeah sure, if I'm doing something that needs to be represented in a UI, then a form makes sense. But I also have background tasks, API endpoints, all of that only need validation (who doesn't).
I want less code to maintain, and fewer pitfalls I can fall into 😅
This is probably going to result in me creating a niche 3rd-party-app with the Model class of my dreams!
=> More informations about this toot | More toots from valberg@social.data.coop
@valberg @benjaoming Do so! This is the way. (Also, do check that history, as folks have walked this path before!)
https://fosstodon.org/@carlton/113049802528297559
=> More informations about this toot | More toots from carlton@fosstodon.org
@valberg @benjaoming I use Forms for API validation too 😜
=> More informations about this toot | More toots from carlton@fosstodon.org
I love these programming dilemmas or paradoxes, where there's no ultimately right answer. When people can't agree to an exact simple solution, it's better to try to transform the problem into the dilemma that it proposes, rather than looking for a solution.
X vs. Y, where both X and Y can never be satisfied.
=> More informations about this toot | More toots from benjaoming@social.data.coop
@benjaoming 💯 It's absolutely NOT "this is the only way" — but in this case it is the way Django leans (for reasons)
=> More informations about this toot | More toots from carlton@fosstodon.org This content has been proxied by September (ba2dc).Proxy Information
text/gemini