Enforce field uniqueness in selections

[jml]

Enforce field uniqueness in selections

[teh]

I'm not super sure what this means. Is this to catch a query like this:

{
  a
  a
  b
}

?

[jml]

It's kind of detailed actually. I'll try to sum up:

Handle fragment spreads

e.g. This is a valid query:

{
  foo
  bar
  ... myFrag
}

fragment myFrag {
  bar
  qux
}

And the output should look something like:

{
  "foo": 1,
  "bar": 2,
  "qux": 3,
}

Aggregate identical fields

e.g.

{
  a
  b
  b
}

Should just be processed as if it were:

{
  a
  b
}

Bork on non-identical fields

{
  a
  b
  b(1)
}

[jml]

Relevant parts of the spec:

• https://facebook.github.io/graphql/#sec-Field-Selection-Merging
• https://facebook.github.io/graphql/#sec-Field-Collection
• https://facebook.github.io/graphql/#sec-Value-Completion (esp. MergeSelectionSet)

Reason all these are together is because the implementation for all of them will involve changing the type of SelectionSet in validation. Currently, it's a list of Selection, but it'll probably become some sort of OrderedMap or at least something more structured.

Probably also FragmentSpread will disappear from the fully-resolved type, which will be a mercy.

Anyway, as you can guess from this commentary, I'm at the level where it's easier for me to code it than to explain it.

[jml]

Also!

{
  a {
    foo
  }
  a {
    bar
  }
}

=>

{
  "a": {
    "foo": 1,
    "bar": 2
  }
}

[jml]

The way this works in the spec is that validation confirms that everything is mergeable and at execution each selection set gets flattened to fields only (one level at a time), and then evaluated.

The natural thing to do in our approach would be to flatten everything in the validator, but we this doesn't chime with the way we're doing unions (which I understand less now than I did before I started reading the spec).

Will continue to mull.

[jml]

Here's where I've got to conceptually. Don't know how this fits into our code.

• after validation, each selection set will be a thing that contains:
  • fields
  • inline fragments with type conditions
  • no fragment spreads
  • i.e. a slightly narrower Selection (with no need for spread type parameter!)
• although validation can check for uniqueness across those, it'll be extremely difficult to construct a value that guarantees uniqueness (e.g. a map)
• however, instead of thinking of it like a mixed bag of Selection as we currently do, we can think of is like a function: TypeName -> OrderedMap FieldName Field
  • that is, once we know the type that the selection set is for, we can immediately flatten it to an ordered map of unique fields
  • might be an error condition in the type too, if the type name is not one that's in the selection set
  • if we do this, the Resolver becomes a thing that operates only on SelectionSets and Fields—a nice property, IMO—also eliminates possibility of duplicate fields and gives us the merging behaviour above "for free"

Still mulling though.

I think this (and lots of other things) will be easier with end-to-end, which will allow for easier experimentation.

[teh]

Thanks, that was useful! My initial reaction is that after FragmentSpread has been resolved it should be possible to rewrite the nested SelectionSets into a single, well-formed SelectionSet query, including union for which we can treat each InlineFragment separately: it's a sum type and we'll chose exactly one. I'm sure I'm missing something so let's chat tomorrow!

[teh]

After discussing this in person we can probably implement this by rewriting the selectionSet in the HasGraph m (API.Union unionName objects) instance. Whether we do that by making all selectionSets a function that take e.g. a PickBranch Name or whether we do that locally in just the Union instance depends on which design will be easier in the end.

[jml]

I have a branch for this in progress. Can do basic leaf/non-leaf validation without schema and can do pretty solid validation + nice API for resolver with schema

…

On Sun, 22 Jan 2017 at 14:34, teh ***@***.***> wrote: After discussing this in person we can probably implement this by rewriting the selectionSet in the HasGraph m (API.Union unionName objects) instance. Whether we do that by making all selectionSets a function that take e.g. a PickBranch Name or whether we do that locally in just the Union instance depends on which design will be easier in the end. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHq6taGm6k6-Zu5XjPms5gUS5lon91kks5rU2jZgaJpZM4LZPjI> .