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

Uniqueness of field aliases #1128

Open
wutsch0 opened this issue Nov 21, 2024 · 3 comments
Open

Uniqueness of field aliases #1128

wutsch0 opened this issue Nov 21, 2024 · 3 comments

Comments

@wutsch0
Copy link

wutsch0 commented Nov 21, 2024

Both the latest released spec and the working draft don't contain any information on field alias uniqueness requirements.
Field aliases need to be unique at least within the same object by common sense, but it is not specified if they need to be unique globally within the whole request or can be reused in different objects.

Deciding for the one or the other could be a breaking change for existing implementations.

To my understanding of the Contribution guidelines, deciding on that topic requires to follow the RFC process, which requires a champion to pick up this topic 🙏

@martinbonnin
Copy link
Contributor

martinbonnin commented Nov 21, 2024

My very superficial/immediate thoughts on this is that the field merging validation takes care of this. It's okay to have the same alias multiple times as long as fields can merge:

{
  foo: user {
    name
  }
  # this is OK
  foo: user {
    email
  }
}

It should also be fine to use the same alias in different objects. Or is there somewhere where this is problematic?

@wutsch0
Copy link
Author

wutsch0 commented Dec 4, 2024

I still need to read in detail through the field merging specification, but I did understand that this actually tells about uniqueness requirements.
As this is not easy to parse an not obvious where to find, I think adding a paragraph to 2.7 Field Alias section would be helpful.

To my understanding this addition wouldn't require the RFC process, as its not changing the spec but improving legibility. I'll try to come up with a PR soon

@benjie
Copy link
Member

benjie commented Dec 4, 2024

This would indeed be an editorial change. We look forward to your PR @wutsch0 🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants