-
Notifications
You must be signed in to change notification settings - Fork 770
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
Add filter instance to Filter.method
signature
#1150
base: main
Are you sure you want to change the base?
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1150 +/- ##
==========================================
+ Coverage 99.43% 99.43% +<.01%
==========================================
Files 15 15
Lines 1235 1237 +2
==========================================
+ Hits 1228 1230 +2
Misses 7 7
Continue to review full report at Codecov.
|
Just a question: Does |
The |
This feature is very useful, I am using part of the code to define negations in custom methods. |
66d4f67
to
9f1a64b
Compare
Okay, this should be ready for review. A few thoughts:
|
Codecov Report
@@ Coverage Diff @@
## master #1150 +/- ##
=======================================
Coverage 99.44% 99.44%
=======================================
Files 15 15
Lines 1255 1269 +14
=======================================
+ Hits 1248 1262 +14
Misses 7 7
Continue to review full report at Codecov.
|
Any progress? This feature is very useful, I would like to see it merged. |
Filter.method
enables ad hoc filtering behavior, however the current implementation does not sufficiently support writing more generic methods, as you cannot easily access the associated filter instance or its properties. With the filter instance, the method could alter its behavior, like whether it shouldexclude
or use a specificlookup_expr
. This PR proposes changing the method callback signature to provide the filter instance in lieu of the model field name.Context:
Let's work with the following example:
With the current implementation, it's not possible for
date_filter
to differentiate between the three filters, as only thefield_name
is provided as context, and all three filters reference the same field.Current workarounds involve either abusing the
field_name
to provide both the attr/field names (e.g.,field_name="<attr name>-<field name>"
) or to usefunctools.partialmethod
. e.g.,Proposal:
Change the signature to include the filter instance instead of the
field_name
. e.g.,Because the first positional argument has changed from the
QuerySet
to aFilter
instance, this should raise a loud, but easy to fixAttributeError
. There might be a possible deprecation path here (check forAttributeError
and object type, then retry with old signature call), or at a minimum, we can catch allAttributeError
s and reraise with an explanatory message.TODO: