The one exercise I would love is calculate rolling retention. It's a very common SaaS metric but really hard to get/calculate. I don't know any ORM that does it elegantly.
SQLAlchemy isn't an ORM, it has one. The docs you've linked only show how to use window functions using the Expression Language that allows you to construct SQL in Python. There is no indication at all on how to use that with the ORM.
the ORM is built on top of the expression language, and the entire design is that Core expression units are fed into ORM functions that consume them. So there is no separation between a Core SQL construct and the ability to use it in the ORM. In earlier versions there were some limitations here and there moving from Core to ORM as far as how result sets could be constructed, but on the SELECT side all of those are ancient history. My talk at http://www.sqlalchemy.org/library.html#handcodedapplications... is entirely about translating from SQL to the ORM and focuses on a problem that uses a window function.
You're totally right of course. I was to focused on the idea of creating queries based on models and somehow getting models back. Somehow I got caught up in this completely wrong way of thinking about the problem.
I greatly enjoyed watching the talk. You make it obvious what to take away from the talk and your explanations are easy to follow along with. In the first part of the talk, you really took advantage of Python's dynamicity to describe something very static. I hope that's something that will stay in my mind and change how I write code in the future.
Despite the marketing the ORM is very much distinct. You can use SQLAlchemy without ever touching or even knowing about the ORM.
The Expression Language on which the ORM is built on is more powerful than the ORM itself. You can do asynchronous IO with the Expression Language or generate SQL with it that you couldn't with the ORM.
This distinction matters. You can't just point to somewhere in the SQLAlchemy docs and say argue that because SQLAlchemy allows you do to X, there exists an ORM that can do X. Calling SQLAlchemy an ORM is a simplification that may be fine in some contexts but it ultimately isn't true.
Slick is the coolest ORM I have ever used. The way it lifts SQL types into Scala code is something I have never seen done elsewhere.
That being said it was also one of the hardest libraries for me to learn. The docs are okay but it seemed like I found more features in peoples github repos that were not documented on the Slick website.
