Skip to content

Support for @SchemaMapping and @BatchMapping based off interface type #294

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
francis-a opened this issue Feb 18, 2022 · 5 comments
Closed
Labels
status: superseded Issue is superseded by another

Comments

@francis-a
Copy link

francis-a commented Feb 18, 2022

I'm having a hard time registering a @SchemaMapping function that should be used as a data fetcher for all subclasses for an interface.

Given the example schema:

interface User {
    username: String!
    color: String!
}

type PurpleUser implements User {
    username: String!
    color: String!
}

type GreenUser implements User {
    username: String!
    color: String!
}

type Query {
    userGet(username: String): User
}

And the following Kotlin model:

interface User {
    val username: String
}
data class PurpleUser(override val username: String) : User
data class GreenUser(override val username: String) : User

My expectation is that by defining a schema mapping for the User interface I would be able to register a data fetcher for the color field on all User subclasses.

  @SchemaMapping(typeName = "User", field = "color")
    fun mapColor(user: User): String {
        return when(user.username) {
            "purpleUser" -> "purple"
            "greenUser" -> "green"
            else -> throw RuntimeException()
        }
    }

However in this example the following query:

{
  userGet(username: "green") {
    username
    color
  }
}

Results in an exception.

{
  "errors": [
    {
      "message": "The field at path '/userGet/color' was declared as a non null type
....

Registering a @SchemaMapping for both concrete types (PurpleUser and GreenUser) fixes this issue.

Is it possible to configure this in a way to avoid duplication of mapping annotations across concrete subtypes? I've included a sample project that demonstrates this issue.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Feb 18, 2022
@francis-a
Copy link
Author

Attached is a simple project that hopefully explains this in more detail

spring-graphql-issue-294.zip

@rstoyanchev
Copy link
Contributor

As far as I can see this is the same discussion as #236. One additional thought is to check if color selected and handle it in the query method:

@QueryMapping(name = "userGet")
fun userGet(@Argument(name = "username") username: String, fieldSelectionSet: DataFetchingFieldSelectionSet): User? {
    if (fieldSelectionSet.contains("color")) {
        // ...
    }
    // ...
}

@rstoyanchev rstoyanchev added the status: waiting-for-feedback We need additional information before we can continue label Apr 19, 2022
@spring-projects-issues
Copy link
Collaborator

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

@spring-projects-issues spring-projects-issues added the status: feedback-reminder We've sent a reminder that we need additional information before we can continue label Apr 26, 2022
@spring-projects-issues
Copy link
Collaborator

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged and removed status: waiting-for-feedback We need additional information before we can continue status: feedback-reminder We've sent a reminder that we need additional information before we can continue status: waiting-for-triage An issue we've not yet triaged labels May 3, 2022
@rstoyanchev rstoyanchev removed the status: waiting-for-triage An issue we've not yet triaged label May 13, 2022
@rstoyanchev
Copy link
Contributor

Superseded by #871.

@rstoyanchev rstoyanchev added the status: superseded Issue is superseded by another label Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: superseded Issue is superseded by another
Projects
None yet
Development

No branches or pull requests

3 participants