4 ms·

Interesting. I don't think django implements a lot of this in their ORM.

• hcarvalhoalves 12y ago
  Django's ORM is very limited, it doesn't even expose GROUP BY. I don't think there will ever be support for more powerful constructs like these.
  • lastofus 12y ago
    You are right in that the Django ORM will always be relativly simple, but it does have some GROUP BY support: https://docs.djangoproject.com/en/1.7/topics/db/aggregation/#topics-db-aggregation https://docs.djangoproject.com/en/1.7/topics/db/aggregation/...
    • hcarvalhoalves 12y ago
      I'm aware, I was already years deep into Django when they released it. But since it doesn't expose GROUP BY (the aggregation API only covers a subset of the uses), when you need it you have to drop to raw SQL, in which case your query will not return a QuerySet anymore, breaking compatibility with the rest of the codebase, defeating the point of an ORM in the first place. An uphill battle.
      • jsmeaton 12y ago
        We're getting closer to full support for custom/advanced queries with full queryset support. See the release notes for 1.8 expressions: https://docs.djangoproject.com/en/1.8/ref/models/expressions/ https://docs.djangoproject.com/en/1.8/ref/models/expressions... The GROUP BY still isn't exposed directly, but neither are joins or subqueries. The rules that make up what should be included in the group by are fairly elaborate. However, writing custom expressions will now allow you to craft some pretty cool SQL, and allow the sub-expression to specify whether it should contribute to GROUP BY or not. Disclaimer: I did a lot of the work for query expressions in 1.8. The ORM team is expanding, and people are actively working on bringing more powerful features to the ORM.
      • meric 12y ago
        You can use a Meta.managed=False model and a Postgresql view and map your model to that view for custom SQL. And just query from that model as normal.
  • collyw 12y ago
    Group by is kind of implicit depending on the model you start with. Model_a.objects.all().select_related(extra_tables).aggregate(arg_params) will group by the Model_a table.
• qooleot 12y ago
  I work on several Django apps, and also write advanced SQL in Postgres (CTEs, plv8 functions, materialized views, etc.). One thing the ORM allows though is writing a custom sql query and its pretty easy to 'cast' the sql results into a Django model. With that said, its still sometimes a struggle to justify if almost all the queries are highly custom, and the app doesn't require Django Admin. Certainly there are advantages, but the minimalism of Flask and focusing on the REST interface for integration and building micro services is more appealing in some cases.
  • IndianAstronaut 12y ago
    If one wants to use these Postgres features, Flask without an ORM is the way to go. Django is too constraining, especially with its primary key limiting.
    • collyw 12y ago
      If you use Django without the ORM, why would it be any more constraining than Flask? I usually try to keep my queries within the ORM, as it means things like sorting and pagination become very easy, but its lacking in certain areas.
      • Iftheshoefits 12y ago
        It's not necessarily more constraining, but from my perspective there are two reasons to choose Django over other python frameworks: the ORM and the out-of-the-box Admin (which depends on the ORM). If you take those away, there is no good reason, in my opinion, to choose Django over, say, Tornado. I wouldn't choose Flask for anything; it's too slow, even by the relatively poor standards set by Tornado and Django.
        • IndianAstronaut 12y ago
          > wouldn't choose Flask for anything; it's too slow, even by the relatively poor standards set by Tornado and Django. What are your picks for good and fast web frameworks which are also light weight?
• jfb 12y ago
  SQLAlchemy supports many of these advanced concepts.