-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subqueries and interfaces, not working at least in one case #467
Comments
Looks like for some reason this
|
So I've been staring at this one, and actually I am not sure if it's supposed to work—at least not in general. I think the issue is this bit: ... on Gcal $GcalStepConfigSubquery I have a recollection that we discussed at one point, how fragments and subqueries actually do not mix. Because in the general case fragments are actually defining a new result type (that would not match the subquery's type). e.g. in this example, fragments are creating a new result type that includes query HeroForEpisode($ep: Episode!) {
hero(episode: $ep) {
name
... on Droid {
primaryFunction
}
... on Human {
height
}
}
} If my analysis is correct, then I think we should consider:
Thoughts? |
You are totally right. Interface queries don't necessarily materialize into an instance. We should extract a subquery on the actual instantiated type ( We could still define reusable blocks for these cases (ie: special case), and I think it would be just a string with the subquery (no output type or decoder), only that we would have to resolve the interpolation at compile time, like we do for actual subqueries. I wonder if this is worthwhile, thoughts? Do you think this it's straightforward or that I'm missing something? |
Oh, I see! So in this case, we just want to interpolate the string part of the query, and not share/reuse data classes? Did I understand correctly? |
Yes, that's what I mean. In other words, compile-time concatenation. It might be useful too when there are common fields but not a common interface. WDYT? |
Yes, I do think that would be useful! I actually attempted that when I first started working on subqueries, because I assumed it would be helpful. It turned out to be difficult and not strictly needed 😂 I still have the branch lying around, I can give it another shot :) the strategy I was trying to use there, was that the Scala compiler will automatically concatenate |
In the ODB we have in the schema:
If we define a subquery:
and then query:
This results in:
The text was updated successfully, but these errors were encountered: