Support renaming fields without defining resolver or more than necessary complexity

[nort3x]

suppose that i have this setup:

class Entity{
     ...
    Something prefixedSomething;
}

@Controller
class GraphController{

    @QueryMapping
    Entity getEntity(){
        return entity;
    }
}

type Query{
    getEntity: Entity!
}

type Entity{
   ...
   something: Something! # attention here , this is not prefixedSomething
}
type Something{...}

i couldn't find a way to resolve Entity.prefixedSomething as Entity.something beside explicitly adding another method
with @SchemaMapping(type="Entity", field="something")

which i think should be reserved for something more complicated than just a simple name override,
i couldn't find anything in docs, i'm looking for more compact way (possibly annotation based)

[trehak1]

Would my suggestion in discussion for #630 to implement general method call instrumentation address your issue?

[nort3x]

yes and i like your proposal,
i will join this discussion
thank you

[rstoyanchev]

@nort3x is this a common prefix across your entities? How do you actually access the value, is there getPrefixedSomething(), or is it prefixedSomething()? I presume you've considered an additional getSomething() method.

Generally, this sounds a lot like it's in the area of PropertyDataFetcher, which tries a few ways to obtain the value from the source. It used to suipport an @fetch directive, but seems to have been removed in GraphQL Java 20.

In any case, if you could elaborate on your use case for a start.

[rstoyanchev]

This is the FetchSchemaDirectiveWiring that supported @fetch. It shows one fairly straight-forward way to re-wire properties, but again a lot depends on the use case.

[rstoyanchev]

Some more background on the deprecation in graphql-java/graphql-java#2455. Seems related to avoiding an automatic schema traversal out of the box for every application irrespective of whether they need it or not.

[nort3x]

@rstoyanchev i faced this issue when i had an entity which holds request/response of some call as @Embeddable which had name clashing so i decided to prefix them (because dealing with Jackson was easier than JPA overrides) and then i noticed how unnatural graphql schema would be with these prefixes, i just need to rename the fields ( i'm using Kotlin so i think it generates standard getter functions out of the box) i think of @JsonName, surely we can do this but here is my biggest concerns:
i think naming/mapping conventions should all be included in DTO ( not magically be handled from somewhere else) it's the ideal situation.
i'm not pointing about impure-DTO extra functionality like #630, it's just a name binding and i'm suggesting we expose this like many other serializations conventions inside the DTO itself.

[nort3x]

i also need to mention although @fetch (or in general any) directive can be used to handle this task, but i would argue with you that schema is read-only for me and it should be agnostic about my actual implementation it's just a coupling to the actual implementation which is not what should we vote for

[bclozel]

@nort3x If I understand correctly, your use case involves a JPA entity with @Embeddable that does not map well with the GraphQL schema. In this case, just like in #630, I don't think we can really think about this feature as DTO fields renaming: we're very much dealing with domain classes here.

i also need to mention although @fetch (or in general any) directive can be used to handle this task, but i would argue with you that schema is read-only for me and it should be agnostic about my actual implementation

I think the same argument could be made against using domain model classes as schema types and exposing them directly: we're tying our database schema to the public GraphQL schema. An update in the database schema might require adaptations to be still compatible with the GraphQL one.

This conversation is not really specific to GraphQL support, we're seeing the same issues with REST services; except that in this case, Jackson annotations on domain classes won't have any effect as we're not using Jackson to produce the GraphQL response.

Have you considered using Spring Data projections or an object mapping library?

[nort3x]

yes projection is directly addressing this issue, at first glance i thought having a more specialized way is convenient but many of this specialized make module very crowded and unpleasant, a more general way is always better.

thanks for pointing me in right direction @bclozel , I'm closing this issue but anyone is welcomed to discuss this more if you find this approach unsatisfying.