Hacker News Reader

Comment by leoh | Hacker News Reader

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

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.

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.

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.

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.

> 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?

The admin has stopped m going to another framework before.

My additional reasons for choosing Django over a minimalist framework:

There is a large selection of third party add ons for Django. I had a look around I couldn't find anything like reversion for any other framework (maybe it exists, but I didn't find it).

There are a standard set of components, so you get a default choice. These will work together and likely have some consistency in the way they get used. Choosing your own components for Flask (or whatever framework), they may well work together, or you may get problems.

You can work around a lot of django's ORM limitations and end up with something that's less laborious and error prone than writing SQL for everything.

Same goes with Doctrine.

You can write crazy complex hydrators, or use simple result set mapping for populating custom query results into objects.

Nearly all of my complex queries for some analytics software I wrote lives in sql statements that aren't inlined in the EntityRepository of a specific entity. ORM's are nice, but doing complex stuff in DQL (doctrine) or the other query builders is more hassle than its worth.

SQLAlchemy supports many of these advanced concepts.

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.

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/...

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.

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...

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.

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.

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.

Reply on news.ycombinator.com