Replies: 3 comments
-
|
Thanks for pointing out we don't have documentation yet for the unusual configuration! |
Beta Was this translation helpful? Give feedback.
-
This was done on purpose - 25 is meant to be a breaking change release. The reason was to avoid confusion Previously we had but the value was always 100% a But now for performance reasons we no longer wrap objects in a FetchedValue unless we need do So rather than re-use the method and confusing things we made a breaking change to reflect the new behavior. So a consumer cant accidentally run the same code and get class cast exceptions unexpectantly say. |
Beta Was this translation helpful? Give feedback.
-
|
Oh ok, all clear then… thanks! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
hi all :)
We completed the upgrade from graphql-java 24 to 25-beta5 to take advantage of the new
ResponseMapFactory, with something like:GraphQL.unusualConfiguration(executionInput).responseMapFactory().setFactory(ArrayMapResponseMapFactory.INSTANCE);In general the upgrade was smooth... we just found a single breaking change in
InstrumentationFieldCompleteParameters: the methodgetFetchedValuewas renamed togetFetchedObject.Maybe it is possible to avoid even that by keep the old method?
Additionally the javadoc for
FetchedValuestill mention this:Note: This MAY be returned by InstrumentationFieldCompleteParameters.getFetchedObject() and therefore part of the public despite never used in a method signature.but perhaps it is not needed anymore as it is annotated with
@PublicApinow.As final feedback, the UnusualConfiguration mechanism is cool and well architected but I was not able to find some nice documentation / blog post about it.
My 2 cents,
D.
Beta Was this translation helpful? Give feedback.
All reactions