[rtpg]

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.

[jsmeaton]

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

[rtpg]

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.

[0]: https://code.djangoproject.com/ticket/24386

[jsmeaton]

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.

[rtpg]

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