sibling mentioned ORM migrations not being built in.
It used to be that it was very hard to write custom expressions or aggregations (like `SUM`) in a way that would be first-class with ORM-provided expressions. This has been massively improved, and been made into a public API. So if the ORM doesn't support something you can write it easily.
The core has also been majorly rewritten, which has made entire classes of bugs disappear. Before 1.8, it was possible to write expressions where the filters got so complex that the ORM would just give up.
The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare.
This doesn't happen anymore.
A lot of old Django core code isn't really super durable, and you get a lot of pain because of it. But the past couple of releases have cleaned up a lot of code, making Django into an extremely clean project.
> The way the ORM would give up is drop all filters. So you write your 3-line filter, and the ORM does nothing. It doesn't blow up, it just does a straight SELECT call on the table without filtering. A nightmare.
Is this really true? Can you point me at any tickets or examples? Everything else you've said is bang on though.
Ah, I feel bad, because I ran into this twice and didn't report this properly. The situations I ran into happened whenever I would combine filters and excludes, along with some joins. The system would simply drop filters, and just do a plain SELECT on the table. But ever since the 1.8 ORM update, I have no longer been able to reproduce this, so have assumed it was fixed through cleaning up the internals.
I did report a related bug[0] where the ORM gets confused by complex queries, but it didn't just drop the filter. It blew up, which is better but still a bit concerning.
Exclude filters are awful and very unintuitive if you know SQL in my experience. I'd much prefer to use negated filters like: `.filter(id__notequal=3)`. I'm giving a talk at djangocon AU in a couple of weeks where I'll step through examples like this.
Right. Worse case, you can use `~Q` or the like. The way I recall it, this didn't solve the issue (as in: something more fundamental than "using exclude instead of filter"), but I no longer have the example...
Was pretty limited and very very inferior to SQLAlchemy. It still is, but it's bearable.
As an example off the top of my head when I started with Django you couldn't bulk create objects, if you wanted to create 100 records it needed 100 separate INSERT statements. That got old fast.
Edit: Not sure why the downvotes, perhaps comment on why you think I'm wrong?
Yep, but as I said it's still rather limited compared to SQLAlchemy. Stuff like aggregations are cumbersome, and it's really really easy to shoot yourself in the foot and cause O(n) queries (especially in templates and in custom admin views).
Things specific to Postgres are rather lacking. While they added support for advanced datatypes like arrays, hstore, intervals and search recently (yay!) you still can't use any other index than a standard btree one or things like recursive queries. SQLAlchemy supports all of these, and has done since forever.
Things are progressing, don't get me wrong, but there is a long way to go.
SQLAlchemy has a lot more power than Django's ORM. I'd argue that Django's ORM is more accessible to beginner SQL users though. Django handles joins for you (which admittedly breaks down with very complex queries) which is the only ORM I'm aware of that does. SQLAlchemy maps much more closely to SQL and is a tighter abstraction.