Is there any way to transform variables before resolving fields?
SomeAkk opened this issue · comments
Is your feature request related to a problem? Please describe.
We got queries with variables. One variable is popular and it's need to be transformed every time when query calling.
Describe the solution you'd like
Need something function like transform_before_xvariablenamex() or another variant to transform variable before start to use it in resolve_xxx()
Describe alternatives you've considered
I do not want to write some ugly function and import it to resolvers of fields of models where that variable is come in.
Additional context
Need something like in marshmallow, when they transform data before use it in functions.
Do you have an example use case for this?
Solving this for query variables exclusively is problematic since users are always free to not use variables and directly insert the data into the query, skipping all your variable processing.
If you're talking about resolver arguments in general (not limited to those passed using variables), injecting the processed values into info.context via e.g. middleware would be another option. If you come up with a more detailed example I might be able to give you more specific guidance.
Maybe that will smels, but it is our code.
So: in variables we got services cross filters.
It's like "our_awesome_dsl" which used for filtering data in backends: main idea to make frontend's live simple and give them "one instrument".
Because of long migration to that silver dsl in other services, we need sometimes to transform input filters (our common library for python use current version and not work with deprecated dsl versions) so we write bicycles and transform that filters to new form and then in right interpretation feeding it to common library (looks like middleware, but in resolver functions).
Now i use for that resolvers, but thing that it is not good idea: call "transformer function" right from resolvers. Function transform dsl filter in variable and so on.
I don't think this is a task that should be tackled in graphene, but rather in your user implementation. I've already mentioned the context as a way to pass processed results down to other resolvers that might need them. You could transform your input in the respective top level resolver that receives the input and add it to info.context["custom_processed_field"].
Apart from that, it's hard to come up with a more specific example without looking at the specific design needs of your schema.