4 ms·

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

• platz 10y ago
  Window functions... ORMs will probably never support them
  • joostdevries 10y ago
    I use Slick to access Postgres and it does support postgres window functions: https://github.com/tminglei/slick-pg#details https://github.com/tminglei/slick-pg#details
    • platz 10y ago
      Impressive!
    • Deinumite 10y ago
      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.
  • urschrei 10y ago
    SQLAlchemy has, for a while: http://docs.sqlalchemy.org/en/latest/core/tutorial.html#window-functions http://docs.sqlalchemy.org/en/latest/core/tutorial.html#wind...
    • DasIch 10y ago
      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.
      • bogomipz 10y ago
        From the top of http://www.sqlalchemy.org/ http://www.sqlalchemy.org/ : "The Python SQL Toolkit and Object Relational Mapper SQLAlchemy is the Python SQL toolkit and Object Relational Mapper that gives application developers the full power and flexibility of SQL." So I would say it is in fact an ORM even if it is also a toolkit.
        • DasIch 10y ago
          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.
      • zzzeek 10y ago
        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#handcodedapplicationswithsqlalchemy 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.
        • DasIch 10y ago
          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.