smallrye-graphql
smallrye-graphql copied to clipboard
`@Multiple` for resolver methods
Currently, a resolver method can only add a single field to a target type. We could reuse the @Multiple
annotation from the typesafe client to allow resolver methods to add multiple fields when it's cheap to get them all at once.
E.g.:
@Multiple
class Equipment {
Cape cape;
Suit suit;
}
Equipment equipment(@Source SuperHero hero) {
...
}
... results in a schema like:
type SuperHero {
name: String
team: Team
cape: Cape
suit: Suit
}
I am not sure about this. This does not feel right. But I am not sure why. @jmartisk w.d.y.t ?
I think that adding multiple fields should be possible, but shouldn't this work even without the annotation? Why should we require it?
Even if we decide that we need an annotation, I would not reuse something that has client
in its package name.
Without the @Multiple
annotation (which would have to move to the common api), the schema would be:
type SuperHero {
name: String
team: Team
equipment: Equipment
}
type Equipment {
cape: Cape
suit: Suit
}
I want the fields to be inlined, so to speak.
Maybe a @Flattern
annotation ?
I'm fine with a new name, but as the semantic is exactly the same in the typesafe client, we should then rename that, too.
Oh I see. JPA has something similar, but you need two annotations
-
@Embeddable
on the class that you "include" into an entity -
@Embedded
where you perform the embedding, that in our case would be the source method
I don't think we need two annotations, that's a bit too complex.
I'm not sure I like @Flatten
because it could be viewed as somehow flattening the included class, while it's actually more like flattening the outer class. But perhaps this would be resolved if we placed that annotation on the @Source
rather than on the class, so it would work rather like JPA @Embedded
.
So this:
class Equipment {
Cape cape; // also possible to annotate this with @Flatten if cape should be flattened too
Suit suit;
}
@Flatten
Equipment equipment(@Source SuperHero hero) {
...
}