3 ms·
> 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 SELE
by jsmeaton 10y ago
> 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 10y agoAh, 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 https://code.djangoproject.com/ticket/24386
- jsmeaton 10y agoExclude 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 10y agoRight. 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...