You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 16, 2024. It is now read-only.
we have the issue, that we want to replace a field in our protobuf types depending on the context (the DateFetchingEnvironment). The use case for this is that our type contains a map of languages to labels.
We want to resolve the label as a string depending on the Accept-Language Header sent by the client and thus need the context of the request for the type modification.
As far as I understand it, if we use Type.find(...).replaceField(...) we need to implement type coercing which does not have access to the context.
Our approach was to implement two SchemaModifications:
However, it seems we cannot guarantee the order in which the modifications are executed.
Is there a solution to this problem that we overlook?
Otherwise, would it be possible to add a parameter to the SchemaModifcation Annotation that ensures the order in which they are applied?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hello,
we have the issue, that we want to replace a field in our protobuf types depending on the context (the DateFetchingEnvironment). The use case for this is that our type contains a map of languages to labels.
We want to resolve the label as a string depending on the Accept-Language Header sent by the client and thus need the context of the request for the type modification.
As far as I understand it, if we use
Type.find(...).replaceField(...)
we need to implement type coercing which does not have access to the context.Our approach was to implement two SchemaModifications:
However, it seems we cannot guarantee the order in which the modifications are executed.
Is there a solution to this problem that we overlook?
Otherwise, would it be possible to add a parameter to the SchemaModifcation Annotation that ensures the order in which they are applied?
The text was updated successfully, but these errors were encountered: