4 ms·
I really wish Django would let you write raw queries, but wrap them in an object that still allows `.annotate()` and `.filter`, etc. I know you can do Model.obj
by WesleyJohnson 3y ago
I really wish Django would let you write raw queries, but wrap them in an object that still allows `.annotate()` and `.filter`, etc. I know you can do Model.objects.raw(), but I'm talking about a more complex query with nested joins, etc.
I understand why it doesn't allow that, and probably never can, but it would be nice when you need author OLAP queries but want to continue to use as much of the ORM as you can.
- specialist 3y ago(I'm not a Python dev. Sorry.) Guessing .annotation() for runtime type info? .filter() avoids re-executing query just to get a subset? How do the (canonical utility methods) relate to nested JOINs? Because field types of nested sets aren't visible? TIA.
- WesleyJohnson 3y agoDjango's ORM has a Model class that wraps an underlying SQL table to can runs queries in an object-oriented approach. When using utility methods like .filter() and .annotate(), you're executing them against the Model (well a ModelManager to be more specific) so they inherently understand the model (and thus the underlying table) that you're querying against. This allows Django to translate the arguments you pass into those methods into SQL, while also handle SQL parameterization, etc. If the ORM were to allow you do build a raw query, using multiple tables, views, nested queries, etc - it would be difficult for it to then allow those utility methods. The ORM wouldn't have the Model class and it's associated fields to use in while translating the method's args into SQL.