The point of the Query Library is to be able to share queries between apps without copying and pasting SQL code.
The problem is that some queries in the library might need an associated transformer. If I want to use those queries (via “Import from Query Library”), I also have to manually copy and paste the transformer code in each local query.
If would be good to be able to define an optional transformer in QL, just like with do with local queries.
+1 on this request. I just started building a new app that is based on modules and the query library, only to find that transformers aren't supported.
+1 on this request, have some queries in the query library where I have to add the same transformer in each app, and limits the value of the query library.
+1 and Query JSON with SQL should be available in shared query library
One workaround is to use a module 
Any news on this feature? Last mention was two years ago
Hey all, I just checked in with the team in charge of the QL and it actually doesn’t look like we’re going to add this anytime soon, but for anyone else reading this thread, please continue to share your use cases and plus ones to help us properly prioritize!
I def need this. I have SOAP responses that need a fair bit of transforming to make their results useful.
Would also make sense for us. We are using an OData API that need transformation.
Maintaining those in global scripts is not ideal. We also need to get transformation code example from other apps instead of simply use queries from library.
For example, every POST/PATCH calls to our API require a CSRF token that is returned through another call header. We need to transform it in all and every app which leads to a bunch of duplication.
return {
token: metadata.headers['x-csrf-token'].join(),
cookie: metadata.headers['set-cookie'].join()
}
We can put that in global javascript but we'd still need to manually add the transformation to every instance.
return window.parseTokenFromHeader(metadata)
We have made a lot of retool apps for various internal operational stuff now, and have realized that we would greatly benefit from sharing queries between those apps.
Unfortunately, one of the optimizations we've made in the most complicated apps is fetching a lot of data in a single query and using transformers to select subsets of the data. This means the queries rely on associated transformers.
As a result we can't really extract the queries to the query library, since the data is unusable without the transformers. I could refactor the transformers to belong to the query, but this would add a lot of time to the process that I would prefer to avoid.
In other words I would have loved to be able to extract transformers to the query library, and I hope you at some point can prioritize adding this feature.
We would make use of this in a number of cases. Putting the logic with the query reduces the number of places we need to make changes. Exactly what the query library is for.
Definitely valid. Thank you for taking the time to share your thoughts—I passed them along to the team that would be working on this!
This would be useful for us too. We have actions we use to trigger an API action (like initiating password resets) from different places (buttons, click events for dropdowns and tables). We show a response message with a reset link which has to be transformed from the API response. Right now we have to duplicate the transformer code everywhere we want to run that action. Would be great if we could have the transformer in the query library instead so we can just show the response message.
Passed along to the team assigned, thank you!
+1 I use the QL in workflows so I can't even use a transformer in a query without adding a separate block and re-configuring the entire workflow. It would be really nice to be able to embed that transformer in the QL where it will help us stay DRY.
My use case is parsing email templates - I get templates from a MySQL query and then use a transformer to implement flexible/dynamic replacement tags for personalization merge and other data munging before sending via email.
So, the presence of a transformer in the QL would help us not repeat the code required to parse the various types of templates and more easily support a variety of dynamic/user-generated tags.