No, parameterized cascade does not quite fit the bill here. It would for some use cases but not this one. The general use case is combined filters at multiple levels. Here is my related topic when I was learning about this restriction:
I don’t have the time for a full ellaboration, and it does impose some additional challenges such as DQL does not honor any @auth directive rules in GQL. But the overall idea is this:
- Predefine DQL queries that will be alllowed to use as filters. I save these as FilterOptions type in the DB. I use some place holders for variables and the return variables to enable grouping of these filters using the AND, OR, NOT logic allowed in DQL @filter.
- I added a type Filter that holds the subFilters, joining conjunction, variable values defined by the user and the related FilterOption defined above.
- The subFilters connects to more Filters so a AND filter can link one or more subFilters together.
- I wrote a lambda function that accepts a few parameters and the JWT if available. The main parameters it needs though is which Filter to use and what type to connect it back to.
- The lambda function generates a full DQL query grouping different variable blocks together and how they link back to the requested type. The final line of the script returns a set of uids.
- I then threw this lambda function into a custom query named useFilter and pass the JWT and define the variables needed the the remote type produced.
- Then in the UI I make a call to the useFilter query using graphql and get a list of IDs that match the filter
- Then to conclude this whole hot mess, I pass those IDs received from useFilter to my actual graphql request that gets the filtered data to display.
Maybe this will make it’s way into a full write up benefiting the community sometime later.