#25367 closed Cleanup/optimization (fixed)
Allow expressions in .filter() calls
Reported by: | Anssi Kääriäinen | Owned by: | Matthew Schinckel |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | me@…, josh.smeaton@… | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Expressions in filter calls will allow 3rd party apps to create query syntax extensions (for example .filter(F('some_field').lower() == 'anssi')) style). In addition, having the ability to use expressions everywhere unifies the ORM experience.
Change History (19)
comment:1 Changed 8 years ago by
Keywords: | 1.9 added |
---|
comment:2 Changed 8 years ago by
Cc: | me@… added |
---|
comment:3 Changed 8 years ago by
Keywords: | 1.9 removed |
---|
As noted on the pull request, there are some problems that can't be solved in time for the 1.9 freeze.
comment:4 Changed 6 years ago by
I have a PR that addresses part of this: being able to have an expression that returns a value with an output_field
of BooleanField
used in a .filter()
, or a Case(When(...))
situation.
Does this address enough of this ticket? Or provide any other suggestions?
comment:5 Changed 6 years ago by
The .filter(F(x) == 'foo')
syntax doesn't work, and won't without quite a bit more work (basically, I think this would require the __eq__
method on F
to return a non-boolean, which I think is probably Bad News(tm).)
I think it can be spelled a different way using ExpressionWrapper
.
comment:6 Changed 6 years ago by
Actually, I'm not sure it can - however, I'm not sure that we actually want to support that syntax - does it give anything over Q(x='foo')
?
comment:7 Changed 6 years ago by
Owner: | changed from nobody to Matthew Schinckel |
---|---|
Status: | new → assigned |
comment:8 Changed 6 years ago by
Cc: | josh.smeaton@… added |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Supporting boolean expressions is enough for the framework. It will be possible for 3rd party libs to support more fluent syntaxes by converting algebraic expressions into database expressions, similar to how combinable works. Whether or not anyone attempts to do that is neither here nor there.
I think this is a really good change. Having to annotate to filter is not just cumbersome, but as you've shown also a large performance hit.
The docs might need a little bit of work, but I think the code and tests are fine.
comment:9 Changed 6 years ago by
Needs documentation: | unset |
---|---|
Triage Stage: | Ready for checkin → Accepted |
After some reviews, the patch is still in progress.
comment:13 Changed 4 years ago by
Patch needs improvement: | unset |
---|
comment:14 Changed 4 years ago by
Triage Stage: | Accepted → Ready for checkin |
---|
This would also probably allow
extra(where)
to be removed as discussed on https://groups.google.com/forum/#!topic/django-developers/FojuU0syO8Y , if expressions with 0 column references are allowed.