4 ms·
I don't know if there is already some plugin to make mypy aware of Django models, but that should be possible and would avoid bugs where you misspelled a proper
by bayesian_horse 7y ago
I don't know if there is already some plugin to make mypy aware of Django models, but that should be possible and would avoid bugs where you misspelled a property and it slipped through your quality control and unit-test.
I suspect "raw sql" to be a bigger headache and source of bugs in any moderately complex project.
Most of the use-cases of queries are actually very simple, and there the ORM allows you to simplify the code a lot.
My hints how to enjoy the ORM more: Write custom managers and QuerySets (for example for commonly used filters), write generic views that take QuerySets, take advantage of Models and QuerySet in Form Validation and REST APIs.
If you use the Django ORM like you would concatenate raw SQL, then it ain't gonna be pretty...
- sjwright 7y ago> Most of the use-cases of queries are actually very simple I write web applications / data tools with raw SQL and I find that only about a quarter of the queries are simple. Many have subtle specificity to the joins, subqueries and window functions that return for me almost exactly what I want to output. The problem I see in most people's ORM-powered code is that they lean so heavily on application code to get all the data assembled in the right place and in the right order, resulting in scaling problems > concatenate raw SQL Often dangerous and almost never needed. Parameterised SQL is the right approach.
- Izkata 7y ago> If you use the Django ORM like you would concatenate raw SQL, then it ain't gonna be pretty... Depends on what exactly you mean here. The Django ORM fully supports some things you wouldn't initially expect if you hadn't seen it before, like passing one queryset into the filter args of another. It'll actually compose the queries and run it once on the database, instead of running the first and passing the result into the second.