-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Define Data Collections used in the spec #1102
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for graphql-spec-draft ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
**List** | ||
|
||
:: The term _list_ describes a sequence of values which may not be unique. A | ||
list is ordered unless explicitly stated otherwise (as an "unordered list"). For |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure "unordered list" makes sense. I mean the ability to iterate over something in well defined way, meaning it can be viewed as a sequence of elements, implies an order in my view.
You could maybe argue that unordered list means the order could change with each iteration, but not sure that is helpful in our context.
Maybe we can get rid of "unordered list"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have any examples of unordered lists being referenced the spec currently, as far as I know. Though the List wrapper type only dictates that the serialized result is an ordered list, it doesn't specifically, as far as I know, require that the underlying list is ordered.
A common example of an unordered list that might be exposed through GraphQL would be the result of select * from my_table;
in SQL - this SQL statement has no implicit ordering, and thus may be returned in any order, each time you issue the query you may get a different result even without the underlying data having changed.
I think we should reserve space to reference this concept.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think one logical consistent way to describe these data structures is with a minimal amount of predefined terms would be:
-
Everything is a collection. A collection is a finite group of elements that can be iterated over. The encounter order during iteration is not necessarily stable.
-
A List is a specific collection where each element can be accessed via a stable Integer >= 0, called index and the encounter order is stable. A List allows for duplicate elements.
-
A set is a specific collection where the elements are guaranteed to be unique. The encounter is not necessary stable ("unordered set"), but can be ("ordered set")
(If we need to define unordered set vs ordered) -
A Map is a specific collection of elements, where each element is a pair (called "entry") made of a key and a value. All keys are a set, while all values is just a collection.
The encounter order of a Map can be stable ("ordered Map") or not ("unordered Map")
(If we need to define unordered Map vs ordered)
(Replacement of #1091; to do PR stack with #1092 and #1063)
The spec uses the terms "set", "list" and "map" in many places. This PR defines these terms and their conformance requirements.
This is a change extracted from #1063 as discussed at last night's WG meeting
The next PR in this stack is:
cc @graphql/tsc