pierrejeambrun commented on PR #43204: URL: https://github.com/apache/airflow/pull/43204#issuecomment-2434982295
>When should I utilize a parameter class (the classes declared in common/parameters.py with to_orm and depends methods) instead of adding query parameters directly (like dag_runs_limit: int = 10 in this case)? For example, in the Event Log endpoints, the query should leverage paginated_select, but the paginated_select function depends on a parameter class rather than query parameters. In this case, should I declare all filter classes in common/parameters.py, or would it be better to add a FilterParam with dynamic_depends, similar to SortParam, that could be used across all endpoints? The idea is if the parameter (query or path) is meant to be re-used in other endpoints and implement a common db operation (filtering, sorting, matching, anything), then it should go into `parameters` with our common parameters. If like in this case it is a very specific one, in terms of parameters (a secondary limit index operating on nested ressources) in terms of naming "dag_runs_limit", and in terms of implementation (`.where(recent_runs_subquery.c.rank <= dag_runs_limit)` which is really specific to the subquery), then it's ok to leave it in the router and not bother creating a reusable 'parameters' out of if. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
