Open rpiaggio opened 1 year ago
Looks like for some reason this case
is not matching, and it's proceeding to the next one, where it crashes.
https://github.com/gemini-hlsw/clue/blob/1dc39739b30223dabeaf766b4a9d67775877531f/gen/rules/src/main/scala/clue/gen/QueryGen.scala#L241
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 name
. If on Droid
or on Human
was a subquery, it would not include name
and thus those datatypes cannot be used.
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 (hero
in your example).
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?
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.
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?
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 final val
strings at compile time. So I was hoping we could tap into that somehow.
https://github.com/gemini-hlsw/clue/commits/pr/final-val-document
In the ODB we have in the schema:
If we define a subquery:
and then query:
This results in: