Skip to content

Conversation

@rsmeral
Copy link

@rsmeral rsmeral commented Nov 21, 2025

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:
Screenshot 2025-11-21 at 17 08 53

Changes

Look up the param type from column_types so that
Screenshot 2025-11-21 at 17 08 38

Tests

Added a new test which checks the generated types.

Checklist

  • I have read the CONTRIBUTING document.
  • My code follows the code style of this project.
  • I have added necessary documentation (if appropriate).
  • I have added tests that cover my changes (if applicable).
  • All new and existing tests passed.

@rsmeral
Copy link
Author

rsmeral commented Nov 21, 2025

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.

@igorbenav
Copy link
Collaborator

Awesome, @rsmeral, no worries

@rsmeral
Copy link
Author

rsmeral commented Nov 24, 2025

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:
Screenshot 2025-11-25 at 0 46 00

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants