On Sat, Oct 8, 2022 at 8:44 AM Aaron Smith <aa...@aaronsmith.co> 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 want to update a status attribute on a model.
>
This feels to me like an important symptom -- regardless of ORM design
patterns (which I'll get to in a moment), data mutation should occur only
in well-defined, controlled ways. Having it "scattered around [the]
codebase" is somewhat worrying. In an Active Record ORM like Django, very
commonly this is just methods on the model itself exposing the desired
logical operations ("resolve this ticket", "publish this article", etc.),
while in a lot of Data Mapper ORM setups it would be in a "business logic"
or "domain" object or some sort of Repository pattern or CQRS setup or...
well, lots of options, but either way it would be strongly discouraged to
be directly mutating data from lots of places around the codebase.
I think you (and Django at large) are conflating Validation and
> conversion/serialization/santization/input filtering, I think of them as
> separate concepts.
>
I still think there's a static-versus-dynamic thing going on here where the
type conversion is seen as an afterthought in statically-typed frameworks
simply because they're statically typed (and a similar phenomenon occurs in
Python with Pydantic).
But the basic point -- that a web framework will have to do validation
that's completely independent of the persistence layer -- stands. There are
simply too many use cases for
forms/submissions/payloads/whatever-you-call-them that *don't* get
persisted to the DB, as I mentioned in my original message. Once that's
established, it's inevitable that a validation -- not just conversion --
layer is needed that isn't tied to the persistence layer. And once that
exists, it's reasonable to ask whether having *another* one in the
persistence layer is wasteful/redundant.
Anyway, I've explained this about as thoroughly as I can now. I think the
real underlying problem here is an unsupported generalization from liking a
particular pattern to deciding that pattern is objectively the only
correct/acceptable one. There are lots of acceptable patterns for how to
design and build and use ORMs and surrounding code. Django has settled on
one in particular, and isn't the only Python framework or ORM to have
settled on it. That doesn't mean it's wrong or bad, just that it's
different from the pattern you want or are used to.
And so I am still very strongly against trying to push a
model-layer-validation approach in Django, even optionally. Django's
pattern is fine, and works well/makes sense for a web framework, for the
reasons I've gone over multiple times now. I would suggest once again that
you adapt to it, because fighting against a framework is never pleasant.
Or, failing that, I'd suggest that you look into switching to something
better suited to your preferences.
--
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/CAL13Cg9NBVH-enng5C_4KaSQeRUsWLe5%2BEnkomsgCKXGj2UkiA%40mail.gmail.com.
