smallrye-graphql icon indicating copy to clipboard operation
smallrye-graphql copied to clipboard

`@Multiple` for resolver methods

Open t1 opened this issue 3 years ago • 6 comments

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
}

t1 avatar Jul 11 '21 04:07 t1

I am not sure about this. This does not feel right. But I am not sure why. @jmartisk w.d.y.t ?

phillip-kruger avatar Jul 13 '21 07:07 phillip-kruger

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.

jmartisk avatar Jul 13 '21 08:07 jmartisk

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.

t1 avatar Jul 13 '21 08:07 t1

Maybe a @Flattern annotation ?

phillip-kruger avatar Jul 13 '21 08:07 phillip-kruger

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.

t1 avatar Jul 13 '21 09:07 t1

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) {
     ...
}

jmartisk avatar Jul 13 '21 09:07 jmartisk