Subqueries and interfaces, not working at least in one case about clue

[armanbilge]

Looks like for some reason this case is not matching, and it's proceeding to the next one, where it crashes.

clue/gen/rules/src/main/scala/clue/gen/QueryGen.scala

Line 241 in 1dc3973

case Select(name, _, Select(fieldName, _, _)) if fieldName.startsWith("subquery") =>

[armanbilge]

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:

1. arguably this is a special case, since you are only expanding a single fragment with no other fields. So should it get special treatment?
2. otherwise this probably deserves a nicer error message :)

Thoughts?

[rpiaggio]

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?

[armanbilge]

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?

[rpiaggio]

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?

[armanbilge]

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