Bug or not? Input-variables of type JSON

[taffit]

Hello all,

first of all: ariadne saved my live! While the graphene (and especially the graphene-sqlalchemy) is only half-baken and seems to be created mainly for Django-users, ariadne provides you the flexibility, robustness and easyness, regardless of the framework you use. A big "THANK YOU!" for the framework and maintaining it!

The reason for this post: I hit an issue which I personally think is a bug, but would need confirmation on if this is intended or not.

If you have an input variables for mutations of type JSON, these get automatically converted to lower case, as we have (rightfully) the decorator @convert_kwargs_to_snake_case in place, saving you a lot of work.
The problem is, that it converts the JSON-keys to lower case as well, as it does not distinguish between "normal" variables and JSON, as everything is provided as JSON.

Workarounds I found:

• Alternative 1: Provide JSON-variables as Strings, load these then as JSON and dump it on serializing. Not a clean solution, though, IMO, plus a lot of serialization effort (on the client, then on the server) and especially if you have most of the input already as JSON, an unnecessary effort.
• Alternative 2: Remove the @convert_kwargs_to_snake_case and adapt the input yourself. Probably the easiest one with the least invasion into the app. Although we use it at a lot of places throughout the code and it would save us a lot of work if we could continue to rely on the decorator, as it works flawlessly in our case.
• Alternative 3: Check the possibility of some custom, adapted fallback resolver. Is that even possible?

IMHO this is a bug, as the framework can (it has the schema at its hand) distinguish between input variables and the actual input.

How do you solve such cases? If this is a bug, I would file a bug. I just wanted to confirm that it's not just me, as I'm relatively fresh into the topic.

Thank you in advance
David

[rafalp]

IMHO this is a bug

I'll say its a limitation and design decision. Decorator was designed to be simple, fast, and work in most of cases.

Ofc we could roll in something super complex that introspects the schema, but that would grow up the complexity by a great deal, and I don't see much value when I compare gains to new maintenance burden.

IMHO you are missing alternative no. 4: roll in your own convert_kwargs_to_snake_case fork that takes extra argument (exclude=) that lets you explicitly disable given variables, eg:

@convert_kwargs_to_snake_case(exclude=["input.raw_data"])
def resolve_smthing(*_, id, input):
    ...