How does `Projection` handle Union & Interface types? about sangria HOT 2 CLOSED

Hi, thanks for asking! This is definitely a challenge I faced as well. Just as you described, at this stage we don't have concrete instances, so it's impossible to determine which objects would be returned as a result of an execution.

On the other hand we have the list of possible sub-types, which is known beforehand. My solution to this issue is pretty simple: i just take into consideration all possible fields of all possible sub-types. It's done here:

https://github.com/sangria-graphql/sangria/blob/master/src/main/scala/sangria/execution/Resolver.scala#L365

When you think about it, it's actually very suitable behavior in most of the cases. The are many different ways to represent class hierarchy on DB Level. In relation DB, for instance, it can be a big table with all possible fields. In this case it would be correct to project all possible fields, that are present in GraphQL selection-set. It's just some of them will have null values if particular row is of different type. You can also represent it as several tables (one table for each concrete class). But it's effectively the same, since you most probably will use outer joins at query time. NoSQL databases are also not that much different. In mongo query, for instance, I can provide a list of all possible projections that are interesting for me. If some document does not have particular projected field, the result simply will not include it.

from sangria.

I will close this issue for the moment being, but if you would like to further discuss this or any other feature, please feel free to reopen it.

If you want, we can also continue this discussion in gitter chat: https://gitter.im/sangria-graphql/sangria

from sangria.