-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
AIP-84 Refactor Filter Query Parameters #43947
AIP-84 Refactor Filter Query Parameters #43947
Conversation
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.
Definitely worth pursuing, thanks.
Just a bunch of early comments.
I didn't run it myself but we need to make sure that the documentation is well detected and constructed. On |
cabb68d
to
0b291bb
Compare
Hi @pierrejeambrun, What are your thoughts on the current I have checked the OpenAPI schema at Looking forward to your feedback! |
I think it's great, last time I tried exactly the same, code was working but documentation was missing the appropriate type. I think I was missing the following to make it work:
But indeed having a Generic factory is the best approach, removing the need for type specific factories. Love it. |
9b6c29f
to
28c34e2
Compare
ae70027
to
d329025
Compare
Hi @pierrejeambrun, Follow-UpI noticed that QuestionFor some parameter schemas like Thanks ! |
As long as they are 'reused' and not specific to a fonction I think it's fine to factorize them into |
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.
Nice, should we generalize that to all routes ?
Yes, I believe most routers can adopt |
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.
I think we can do the full refactoring and apply that to all route.
I'm not super comfortable having both old and new parameters system in place and live together until we decide to finalize the refactoring.
A lot of endpoints are impacted, but the change is quite limited, spec and tests are not modified. I would say the change is not that big. (And that would confirm that every case can be handled with that new system)
88817ac
to
7d57e77
Compare
Hi @pierrejeambrun, the refactor for
Let me know if further adjustments are needed. |
adc3de0
to
03d0c56
Compare
Rebased to the latest |
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.
Really nice.
Also as I understand, we keep flexibility by either:
- using
filter_param_factory
forclassic
orm operation that are already handled - can still subclass
FilterParam
and implemet a full custom filter if needed.
- QueryLastDagRunStateFilter - dag_ids of get_dag_stats
03d0c56
to
b2d01db
Compare
Rebasing, merging on green CI. |
* Add FilterParam and type_filter_param_factory * Refactor Get Event Logs with filter_param_factory * Refactor add type option for filter_param_factory * Fix Get Event Logs with latest paginated_select * Refactor Get Assets Event * Refactor List Dag Warnings * Refactor DagRun related - QueryLastDagRunStateFilter - dag_ids of get_dag_stats * Remove unused parameters * Refactor on Dag parameters * Add any_equal to FilterParam * Refactor Task Instance * Fix Get Event Logs type * Fix after rebase * Refactor with search_param_factory * Refactor QueryLastDagRunStateFilter * Fix get_list_dag_runs_batch
* Add FilterParam and type_filter_param_factory * Refactor Get Event Logs with filter_param_factory * Refactor add type option for filter_param_factory * Fix Get Event Logs with latest paginated_select * Refactor Get Assets Event * Refactor List Dag Warnings * Refactor DagRun related - QueryLastDagRunStateFilter - dag_ids of get_dag_stats * Remove unused parameters * Refactor on Dag parameters * Add any_equal to FilterParam * Refactor Task Instance * Fix Get Event Logs type * Fix after rebase * Refactor with search_param_factory * Refactor QueryLastDagRunStateFilter * Fix get_list_dag_runs_batch
related: #43407
Hi @pierrejeambrun,
As we discussed in #43407 (review), here is the current implementation and usage for the refactored filter query parameters. I'd appreciate your feedback before proceeding with refactoring other endpoints to align with this approach.
Since parameter types need to be specified statically to generate the OpenAPI schema, it is necessary to have a corresponding
filter_param_factory
for each common type ( Likefloat_range_filter_factory
anddatetime_range_filter_factory
forRangeFilter
).Thanks!