Adding Entry Point for custom coercion on standard scalars#3145
Adding Entry Point for custom coercion on standard scalars#3145rciummo-linkedin wants to merge 2 commits intographql-java:masterfrom
Conversation
|
So just some thoughts as I think about this change - I just want to list them but I havent yet drawn conclusions from them per se
|
Well I imagine that if starting from scratch, someone who was dealing with these kind of exceptions to standard coercion would just make their own custom scalars from the start. We are in a bit of a unique circumstance where we can't make this backwards incompatible. However, I can imagine that keeping coercion more strict makes all of the native scalars less useable and adding some flexibility makes them easier to use.
|
|
Hello, FYI @bbakerman is adding a way to modify coercion in #3188 |
I want to add an entry point for custom coercion in ValuesResolver.json
Essentially, I'd want to keep the current coerceVariableValues and add another flavor of it that takes a Function<Object, Object> preCoercionFunction.
This would get passed to ValuesResolverConversion.externalValueToInternalValueForVariables where if not-null, would translate the value right before this line here
At linkedIn, our APIs pass around a custom null class instance to represent null (say Data.NULL) instead of the java null. This is an issue for us even pre-v20 because this Data.null instance is converting to a string "null" instead of java null. To work around this we are rebuilding the entire rawVariables map to convert Data.NULL to null before parsing our raw input variables. However, we have found that this may be causing performance issues so we would like a way to be able to do our custom conversions while still using the grapql native scalars.
Beyond that, migrating to v20 for us is a challenge because of the stricter string coercer. Ideally a new type would be made for non-strings that fail string coercion in v20. The reason we want to not build our own new scalars is because currently our APIs are using schemas with the native scalars and creating a new type would make all of our schema backwards incompatible which is not an option for us.