Expose types of filter parameters
Expose types of filter parameters
Description
With a SQLAlchemy model which has
title: Mapped[str]
when a crud_router has:
filter_config={"title": None},
then the generated spec says the param type is any:
Changes
Look up the param type from column_types so that
Tests
Added a new test which checks the generated types.
Checklist
- [x] I have read the CONTRIBUTING document.
- [x] My code follows the code style of this project.
- [ ] I have added necessary documentation (if appropriate).
- [x] I have added tests that cover my changes (if applicable).
- [x] All new and existing tests passed.
Now I realize – this will most likely work only for filters with exact param names (title) and won't work (but also won't break anything) for filters like title__ilike.
I suppose using column_types.get(param_name.rsplit("__", 1)[0]) could do the trick...? I'll only have a chance to try this out next week.
Awesome, @rsmeral, no worries
So, I dug a little deeper, and realized there is some repetition in how filters are parsed and used. AFAICT, there is sort of a missing layer in filter handling – an internal representation of the Filter. There is FilterConfig, but that only contains surface-level information.
Thus, I've added interpret_filters and the Filter type, which contain metadata, which should be sufficient for all places that use filters. For now, it's only used in create_dynamic_filters to get a correct OpenAPI spec for filters, but it could be reused elsewhere too.
I think ideally, this "interpratation" should be run only once, in FilterProcessor constructor, and then reused in its methods.
WDYT? Let me know what you think about this direction. If it looks alright, I'll add/update tests.
Now, the OpenAPI spec is correct also for operators and joined models:
I wasn't sure if relationships can be arbitrary depth (some methods seem to assume that...?), but it seems most code only works with single level of nesting, and only single relationship per entity.