Skip to content
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

Make SchemaMapping @Repeatable #1103

Open
ooraini opened this issue Dec 30, 2024 · 0 comments
Open

Make SchemaMapping @Repeatable #1103

ooraini opened this issue Dec 30, 2024 · 0 comments
Labels
status: waiting-for-triage An issue we've not yet triaged

Comments

@ooraini
Copy link

ooraini commented Dec 30, 2024

This is a minor inconvenience for me. It's just some boilerplate that I would love not to write. Motivation:

In my own usage of @SchemaMapping I often end up deprecating and renaming fields while their schema mapping method doesn't change:

type ... {
  count: Number @deprecated(reason: "use userCount"),
  userCount: Number
}

I'll need two @SchemaMappings:

@SchemaMapping
int count(SOURCE s) { ... }

@SchemaMapping
int userCount(SOURCE s) { ... }

Both have the same source object. So it's possible to register the same data fetcher with both fields.

Another case is when separating types based on access:

type AdminProduct {
  commonField: String
  ...
}
type Product {
  commonField: String
  ...
}

In the controller:

@SchemaMapping(typeName = "AdminProduct")
int commonField(SOURCE s) { ... }

@SchemaMapping(typeName = "Product")
int commonField(SOURCE s) { ... } // COMPILE ERROR: same signature 

@SchemaMapping(typeName = "Product", fieldName = "commonField")
int adminCommonField(SOURCE s) { ... } // COMPILES: but I have to specify fieldName

It's possible to share an interface between Product and AdminProduct and register the schema mapping on the interface type, but that is not often possible and it adds considerable code to the schema. Making SchemaMapping repeatable provides an ad-hoc way of achieving the same thing with much less boilerplate

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Dec 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

No branches or pull requests

2 participants