graphql-aspnet icon indicating copy to clipboard operation
graphql-aspnet copied to clipboard

GraphQL filter case insensitive

Open sergiocbueno opened this issue 1 year ago • 3 comments

Hi,

I've been using this library for a significant time and during my usage I've noticed the bind with the GraphQL filters does not work when the first char is upper case. It is definitely not a blocker, but I believe it would be nice to have if we can ignore the first char case (case insensitive). This library is purely for dotnet and the property standard for dotnet is to start with upper case.

Follow an example below.

image

image

sergiocbueno avatar Aug 07 '23 09:08 sergiocbueno

Hey Sergio,

Your request makes plenty of sense.

From a specification perspective, the variables are binding to the fields of the graph type on the schema (i.e. the fields of Input_OrderContentFilterDto) , not the .NET object that backs it. Since all names are case sensitive in graphql it fails to bind properly.

You could change your naming formatter to render all the fields using proper cased names but then all of your queries would have to change to match. That's probably not something you want.

All that said, a configuration option to allow consumers to relax the binding requirements is a good call out, even if it is off spec. There are plenty of scenarios where this can be advantageous, especially if you are relying on the serialization of STJ or newtonsoft from a third party. Having to update your object models on the sender side to spit out GraphQL compliant json serializations could be quite a pain (especially if you don't fully control it).

I'll put this feature on the road map!

Cheers, Kevin

kevin-carroll avatar Aug 07 '23 21:08 kevin-carroll

would it be possible to change default json formatter to newtonsoft json for input&output in the library?

hanssywong avatar Aug 17 '23 01:08 hanssywong

Hey @hanssywong ,

Yes support for newtonsoft is possible. There is some refactoring that needs to be done (especially for inputs) to support it but it is very possible. I have it on the roadmap but no confirmed timeframe yet.

Bear in mind though, that newtonsoft wouldn't solve the issue this ticket lays out. Any json serialization configurations (newtonsoft or STJ) are out of scope for processing variable data. The data is deserialized into a raw set key/value pairs, devoid of any object context, first. Then its passed to a schema for processing and object materialization.

kevin-carroll avatar Aug 21 '23 22:08 kevin-carroll