I’d never used it before and it was fantastic but I had to drop down to raw sql to do it. SQLAlchemy has had support for well beyond a year.
I’ve used Django since 2008 and I love it with all its warts but I’ve really grown to prefer SQLAlchemy.
On top of that, you’d need to come up with a decent frontend syntax that aligned with the existing methods.
I think Django made a mistake when first defining the language of aggregates by overloading the values() method and not using group(). To support rollup, values() would need to support it but only when used after an annotate. Not nice.
I often think about what it’d take to use alchemy for the sql building beneath the Django frontend. That would open up so many more possibilities and features.
I also ended up writing a very tiny transformer function and using that directly because core only has a couple supported casts and I needed Postgres timestamp types so I could extract and rollup on the year / month / day. That gave me some insight in to some of the patterns in use in “lower level” Django differ from the expressiveness / composability of SQLAlchemy.
Django models are more abstract and anemic in querying, but it means you can use the same API and write access layers for non SQL databases. At work, we have an in memory database, and Elastic Search all queried in an identical way to the Postgres models.
For what it’s worth, I dislike the unit of work model that SQLA uses, but the layered architecture is enviable.