Opened 3 years ago

Last modified 6 months ago

#25367 assigned Cleanup/optimization

Allow expressions in .filter() calls

Reported by: Anssi Kääriäinen Owned by: Matthew Schinckel
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: me@…, josh.smeaton@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


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 (9)

comment:1 Changed 3 years ago by Tim Graham

Keywords: 1.9 added

comment:2 Changed 3 years ago by Adam (Chainz) Johnson

Cc: me@… added

This would also probably allow extra(where) to be removed as discussed on!topic/django-developers/FojuU0syO8Y , if expressions with 0 column references are allowed.

comment:3 Changed 3 years ago by Tim Graham

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 15 months ago by Matthew Schinckel

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 7 months ago by Matthew Schinckel

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 7 months ago by Matthew Schinckel

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 7 months ago by Matthew Schinckel

Owner: changed from nobody to Matthew Schinckel
Status: newassigned

comment:8 Changed 7 months ago by Josh Smeaton

Cc: josh.smeaton@… added
Triage Stage: AcceptedReady 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 months ago by Tim Graham

Needs documentation: unset
Triage Stage: Ready for checkinAccepted

After some reviews, the patch is still in progress.

Note: See TracTickets for help on using tickets.
Back to Top