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 django.
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. Pure boilerplate vs. just calling `full_clean()` on save. full_clean() is even a method already present on Model! Why import a *third-party library* just so a model instance can call it's own method?!? I think you (and Django at large) are conflating Validation and conversion/serialization/santization/input filtering, I think of them as separate concepts. Validation should happen everywhere, because bugs can happen anywhere. Input filtering is a concern of the external interfaces. Other frameworks treat them separately and I find it to be a far more robust and flexible pattern. On Friday, October 7, 2022 at 11:28:58 PM UTC-7 James Bennett wrote: > On Fri, Oct 7, 2022 at 6:21 PM Aaron Smith <aa...@aaronsmith.co> 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 makes me wonder how aware the core developers / old >> timers are of the broader user base's experience. > > > I would wonder how many of these developers you've talked to are used to > working in Python. > > The main standalone ORM package people use in Python is SQLAlchemy, which > *also* does not do validation in the ORM layer. The last time I worked with > Flask, the standard practice was to use Marshmallow to write serializers, > and these days the popular async frameworks like Starlite and FastAPI have > you write Pydantic models. In either case they fill the role of, say, a DRF > serializer -- they do the validation, and data type conversion at the > application boundaries, so that the ORM doesn't have to. > > It's true that when you start branching out into other languages you'll > encounter ORMs which have validation built-in, like Entity Framework or > Hibernate, but you'll also more often encounter that in statically-typed > languages where the data conversion step has already been handled for you. > It's also not always clear that the ORM is the right place for validation, > since often the rules being enforced are ones that aren't actually enforced > at the DB level by constraints. > > Either way, I think I've made the case for why Django doesn't and > shouldn't do this. You seem to have a strong reluctance to use either > Django forms (in a "vanilla" Django project) or DRF serializers (in a more > "API" project) to validate data from sources other than direct > user-initiated HTTP request, but I don't really get that -- the validation > utilities are there, and if you're not willing to use them that still is > not Django's problem to solve -- after all, someone else might be equally > set in their conviction that all the existing validation layers are the > wrong way to do things, and demand we add yet another one, and I doubt > you'd be supportive of that. > > So I think Django should continue to be Django, and validation should > continue to be a layer independent of the ORM (which, as I originally > noted, it *has* to be in a web framework, since not every use case for > validation will end up touching the database). For that reason I'd be very > strongly against ever adding even an optional default enforcement of > model-level data validation. > >> -- 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/888f34cb-1f21-4036-ac16-79be14c74541n%40googlegroups.com.
