[jsmeaton]

Adding new SQL support to the Django ORM is tricky. There isn’t a nice low level abstraction for generating and composing SQL. It’s mostly a bunch of lists containing different kinds of data (strings, Col, Expression) and they don’t compose well.

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.

[leetrout]

Yea I started to bring up the existing ticket for grouping on the dev list and ask what people thought about it.

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.

[true_religion]

SQLAlchemy has a great architecture, but it comes at the expense of being tied to the use case of accessing a relational database.

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.

[jsmeaton]

I’d be super keen to see your ElasticSearch model implementation if you’re allowed to share it?

For what it’s worth, I dislike the unit of work model that SQLA uses, but the layered architecture is enviable.