Skip to content
This repository has been archived by the owner on Aug 20, 2020. It is now read-only.

Silently removing duplicate query names #30

Open
ScallyGames opened this issue May 30, 2017 · 2 comments
Open

Silently removing duplicate query names #30

ScallyGames opened this issue May 30, 2017 · 2 comments

Comments

@ScallyGames
Copy link
Contributor

Current behavior
When defining two queries with the same operation name, only the last one is kept. All other versions are removed.

Expected behavior
Two options:

  • Keep all versions
      • they have different content, thus being different queries that should get their own id each
      • no technical problem as the different strings take different indices on the object
      • convenient
      • can cause misinterpretations when doing performance analysis etc.
  • Throw error if duplicates names exist
      • prevents error
      • forbidding theoretically allowed syntax

Minimal reproduction
Run persistgraphql on

// bar.graphql
query foo {
    foo
    {
        bar
        foobar
    }
}

// baz.graphql
query foo {
    faz
    {
        baz
        fazbaz
    }
}

// result {"query foo {\n  faz {\n    baz\n    fazbaz\n  }\n}\n":1}

Minimal demo

git clone -b duplicate-operation-names https://github.com/
Aides359/persistgraphql
cd persistgraphql
npm install
npm run compile
npm start
@Poincare
Copy link
Contributor

Throwing error seems like the right approach here. I think the generally accepted idea is that you shouldn't have two queries with the same name and it seems reasonable to enforce that. I'm open to hearing alternative solutions to this of course.

@kamsar
Copy link

kamsar commented Dec 28, 2017

In a large application with many developers enforcing unique query names across a big whitelist may not be particularly tenable, so imo this should be a choice with the default throwing an error.

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

No branches or pull requests

3 participants