Replies: 2 comments
-
|
Good point. This isn’t explained in the article. It's been quite some time since I've looked at this, but based on a quick look, I think this is what's happening: When analyzing the pairwise comparisons of the original algorithm, I included the pairs of fields with themselves, which effectively would apply the validation to child selections recursively. This line indicates this:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thanks a lot @acceleratesage. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
While looking at the original blog about a faster overlapping field validation (https://tech.new-work.se/graphql-overlapping-fields-can-be-merged-fast-ea6e92e0a01) and the related Scala/Sangria PR I saw that the Scala implementation doesn't validate every SelectionSet, but rather the whole document once (see https://github.com/sangria-graphql-org/sangria/pull/12/files#diff-7e5472ef514f7f486143163af5eef985388f44ba981e2eb897643ae53fc65428)
This is different to how GraphQL Java does it today: while we have adapted the faster algorithm, we still validate every SelectionSet.
Interestingly in the original blog it is not discussed if the faster algo should be applied once to the whole document or still per SelectionSet.
cc @acceleratesage as the original author of the blog: your input would be highly appreciated.
Beta Was this translation helpful? Give feedback.
All reactions