-
-
Notifications
You must be signed in to change notification settings - Fork 31.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed #25367 -- Allowed boolean expressions in QuerySet.filter() and exclude(). #8119
Conversation
I'm well aware of the superficial issues with this PR (imports and the like). What I want to know is if this is an appropriate approach to implement filter expressions. @jarshwah and I have been discussing this for some time: we thought there might be a whole lot more work to it than this, but it seems to me that we can just inject some logic in to explicitly handle |
A few things off the top of my head:
This is really cool though. I expected there to be a lot more work involved. |
Yes. I'm not sure about the other two: can you elaborate on what sort of queries you mean? Anything that is an expression that has an |
|
076641a
to
9aa41a9
Compare
Okay, @funkybob just showed me a pair of EXPLAINs that shows an order of magnitude improvement by only having the EXISTS in the WHERE clause, rather than in the select. I'm surprised, as I thought postgres would do a better job of optimising this. With EXISTS in SELECT: https://explain.depesz.com/s/xaH With EXISTS only in WHERE: https://explain.depesz.com/s/nc9m |
@jarshwah Currently |
I think we could possibly avoid the need for a |
Hmm. I'm not sure it's possible without quite a lot of work to do anything with a |
9aa41a9
to
19b2213
Compare
fa9ecbc
to
22e4e60
Compare
I am a person and I approve of this feature :) |
👌 I'm a fan, though I'm not sure Django has an official policy. |
Let's get this one merged I reckon. I've made a suggestion for a small improvement, but that's probably all it needs. Couldn't find the ticket (easily) so a link here or a number would be aces. |
26dbcec
to
14370de
Compare
3081a14
to
e6d3515
Compare
6bada76
to
c8a518f
Compare
@jarshwah Finally found the issue: https://code.djangoproject.com/ticket/25367 |
I merged #11652 (Thanks Simon!) we should be able to get rid of |
f4a5cfe
to
034d980
Compare
The pull request was updated against the latest reviews 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's nice to see that the diff is really small now that preliminary changes have landed 🎉
Thanks to everyone involved so far, really excited so this land in the near future.
034d980
to
804ecf0
Compare
I squashed commits, rebased from master, pushed minor edits, and:
I'm going to continue this tomorrow to make final edits (in docs and tests), to add more tests, and to check remaining comments. |
Thanks @felixxm! I'm very busy so I didn't get any time to make changes on the PR and we really need such feature. |
804ecf0
to
c0e3254
Compare
PR didn't work properly on Oracle because it supports only filters and |
@jarshwah Can you take a look at a85460e4da5835a3095462b07b4382033d094371? |
27caea6
to
a85460e
Compare
I pushed all edits. |
…exclude(). This allows using expressions that have an output_field that is a BooleanField to be used directly in a queryset filters, or in the When() clauses of a Case() expression. Thanks Josh Smeaton, Tim Graham, Simon Charette, Mariusz Felisiak, and Adam Johnson for reviews. Co-Authored-By: NyanKiyoshi <hello@vanille.bid>
a85460e
to
4137fc2
Compare
Thanks y'all 🎉 🎊 |
I was doing a bit of archaeology and I stumbled on #4801 (comment). We're not currently affected by that since we don't expose expressions such as |
Here is a first crack at making it possible to do nice things like:
Also: