Replies: 2 comments 6 replies
-
Do you mean in a subschema resolver? That the info argument should have a different path cognizant of the gateway? |
Beta Was this translation helpful? Give feedback.
0 replies
-
Not saying it necessarily should, but being able to retrieve the full
gateway schema path to the resolver within the subschemas resolver function
is the problem I am trying to solve at the moment, yes! Was curious to see
if there would be any sane way to do it.
tis 11 maj 2021 kl. 18:23 skrev Yaacov Rydzinski ***@***.***>:
… Do you mean in a subschema resolver? That the info argument should have a
different path cognizant of the gateway?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#2946 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI7Q7PRIKLNJZP5EQS2A7TTNFKWVANCNFSM44VYBDPQ>
.
|
Beta Was this translation helpful? Give feedback.
6 replies
Answer selected by
ardatan
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello!
In a stitching model with several local subschemas, and given a query that traverses multiple layers of delegation, as such -
path
will naturally resolve to_b.path
(without batch loading). Is there any way to make it resolve toa.b.c.path
, or any other reasonable way to pass on the full path of a specific field from the gateway schema to subschema resolvers?Beta Was this translation helpful? Give feedback.
All reactions