Pattern around fieldsWithResolvers

[thisarattr]

Hi,
I have a schema like below and when I generate api it wont generate a method in Book resolver to resolve Author object.

type Query {
  book(id: ID): Book
}
type Book {
    name: String!
    author: Author
}
type Author {
    name: String!
    age: Int
}

Thus, I did add option fieldsWithResolvers = ["Book.author"] and this adds the resolver for author as required. But now it remove the Author object from Book.

In my DB I have AuthorId in the Book table so I get it alone with the Book which I can pass into Author resolver to fetch Author. But now I dont have authorId in the book so in Author resolver I have to join fetch user from bookId which isnt great.

public class Book implements java.io.Serializable {
    @javax.validation.constraints.NotNull
    private String name;
  ...
}
java.util.concurrent.CompletableFuture<Author> author(Book book, graphql.schema.DataFetchingEnvironment env)

So is there a way to keep Author object as it in Book or add authorId into book instead, both which can be used to get authorId from BookResolver?

Also, is there a way to generate resolvers for all complex types, without me adding fieldsWithResolvers entry?

Thanks! 🙏

[jxnu-liguobin]

Seems to be associated with #606 be similar,

[thisarattr]

Thanks for that!
Its similar to my issue and it will work for me as well. But I dont think it's the best solution as I still need to do more manual work (interface implementation) to get the child id into subResolver.

Most of the time many-to-one and some of one-to-one relationship scenarios child Id is saved along with the parent. so once we resolve parent we hv access to child ID and there should be easy way to pass it into child resolver, so that it does not have to do any additional db calls. so generating ID field/ or keep child object even when there is fieldsWithResolvers for that child object will be really convenient than interface implementation.

[kobylynskyi]

@thisarattr thanks for your request.

So is there a way to keep Author object as it in Book or add authorId into book instead, both which can be used to get authorId from BookResolver?

The idea behind removing the field from the POJO (if it is present in fieldsWithResolvers) was that this field will be "resolved" by a separate Resolver method (in your case author method in BookResolver class), and not be taken from the POJO class.
At the first glance, I am ok with keeping the field in the POJO while generating a separate TypeResolver interface.
We need to think about consequences if we remove this filtering:

graphql-java-codegen/src/main/java/com/kobylynskyi/graphql/codegen/mapper/FieldDefinitionToParameterMapper.java

Line 95 in 4dfce88

fieldDef -> !generateResolversForField(mappingContext, fieldDef, parentDefinition))

---

Also, is there a way to generate resolvers for all complex types, without me adding fieldsWithResolvers entry?
What do you mean by "complex" types?

We currently have the following flexibility around generating resolvers:

• fieldsWithResolvers:
  • The whole type can be specified, e.g.: 'Event', 'Author', etc.
  • Concrete field can be specified, e.g.: 'Event.author', etc.
  • Directive can be specified, e.g.: @generateResolver. Note that this annotation can be added at the type and/or field level.
• fieldsWithoutResolvers - can be used in conjunction with fieldsWithResolvers to exclude some particular types/fields.
• generateParameterizedFieldsResolvers - if set to true then all fields of all types which have parameters (unless excluded) will be considered as those which require a resolver.
• generateParameterizedFieldsResolvers - if set to true then all fields of all types which have parameters (unless excluded) will be considered as those which require a resolver.
• generateExtensionFieldsResolvers - if set to true then all fields of extended types will be considered as those which require a resolver.
  Please let me know what other scenarios you have.
  Thanks.

[thisarattr]

Thanks for your attention to the above suggestion 🙏

What I mean by Complex type is that, in this example Author is not a scalar field in Book type. It's a seperate field type without any parameters, which I need to resolve separately. So shouldn't it generate resolver for those type of fields automatically? (for all non scalar types)

I can't use generateParameterizedFieldsResolvers as this field does not have any params, and only option I have is to add each and every one of those fields in to fieldsWithResolvers, which works fine. but will go out of hand when there are hundreds of types.
every one-to-one relationship will face this.

thanks!

[kobylynskyi]

Ok, now I see what you meant.
We could introduce a new parameter for that (something like: generateFieldsResolversForNestedObjects, with default value as false. What do you think?

[thisarattr]

yeah that will be perfect, so anyone wants this can turn it on and everyone else will see the same behavior as before 👍

[vlagorce]

Any plan to introduce generateFieldsResolversForNestedObjects ?. This would be an amazing feature.

[viacheslav-dobrynin]

Hello, @kobylynskyi!
Is it possible to add an option like addFieldIdForResolving?
As a result, a field will be generated in the object with the desired type.
For the current example it would be:

data class Book(
  val name: String,
  val authorId: String?,
)

[viacheslav-dobrynin]

Created issue to create this (or customFields) option.