this pull request refactors the filter application logic in the API endpoints for retrieving projects, project statistics, credits, and credit statistics. the goal of this refactor is to make the code more concise, readable, and maintainable by using a common approach for applying filters across all endpoints.
Changes:
introduced an apply_filters helper function that takes a query, a SQLAlchemy model, an attribute, a list of values, and an operation as arguments. This function applies the specified operation to the query for each value in the list. it supports ilike, ==, >=, and <= operations. This function is used to handle all filters in the get_projects, get_project_stats, get_credits, and get_credit_stats endpoints.
grouped filters into lists based on the type of operation they apply (ilike, ==, >=, or <=). The apply_filters function is called for each filter in these lists. This reduces repetition and makes it easier to add, remove, or modify filters.
this pull request refactors the filter application logic in the API endpoints for retrieving projects, project statistics, credits, and credit statistics. the goal of this refactor is to make the code more concise, readable, and maintainable by using a common approach for applying filters across all endpoints.
Changes:
introduced an apply_filters helper function that takes a query, a SQLAlchemy model, an attribute, a list of values, and an operation as arguments. This function applies the specified operation to the query for each value in the list. it supports
ilike,==,>=, and<=operations. This function is used to handle all filters in the get_projects, get_project_stats, get_credits, and get_credit_stats endpoints.grouped filters into lists based on the type of operation they apply (
ilike,==,>=, or<=). The apply_filters function is called for each filter in these lists. This reduces repetition and makes it easier to add, remove, or modify filters.