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
Global identification #946
Comments
I believe this stuff belongs to Relay or some other spec, not GraphQL. In real world models in general, having ID is not a universal thing, that each object has. There might be no id field/prop/concept at all, a type/table might have composite key (id composed of multiple fields), and Id field type might vary quite a lot (int? UUID? string), and level of uniqueness might vary as well - nothing to standardize. So ID is not that universal and common, to be standardized in this spec. If existence of ID was necessary for some other feature in spec - that would give it some reason to be (like I guess in Relay); but that's not the situation here. |
There's no way to access directive metadata from the client (#300). |
@glen-84 My main concern with this is that you'd need to query Either way, we still need to solve Lee's nullability concerns which seem valid, though I wonder if they're actually that big of a deal in practice... seems like if |
That's true. If it were only on the schema, it might be easier, since you'd only have to check that once. If there's only one schema @options(globalIdField: "myGlobalId") {
// ...
} ( Could a single option like this work? Are there any implications WRT stitching or federation?
Ultimately, it would be returning non-type-related data via a reserved field name, which I think needed to be avoided.
I didn't really understand the issue with making it nullable. There is surely no flawed assumption if the field is typed as nullable? |
@benjie wasn't there a new push on object identity from the relay team. I remember that Joseph was mentioning this. I could be wrong :) |
@michaelstaib I think there's been some gentle pushes towards something like this from a lot of corners for quite a while; but yes I think Relay may be keen - having the
I don't think that's a hard rule.
Think of it like this: type User implements Node {
__typename: String!
__id: ID
id: ID!
} It's obvious it has a |
I see. With my idea above, the use of |
It could; but we wouldn’t want that. E.g. PageInfo should not have an ID, edges should not have IDs, mutation payloads should not have IDs, etc. |
First-class nodes? # Opt in.
schema @options(nodeInterface: "Node") { ... }
interface Node {
# First/only ID field is the global ID, or use a directive, or a schema option.
myGlobalId: ID!
} |
Looks like that would benefit from #300 |
As discussed in #232,
__id
doesn't really make sense if it actually returns the global ID, since double-underscore fields are usually used for type information. But what if it did return type information (the name of the global ID field), and that field was defined using a directive?The original idea comes from
@leebyron
and@calebmer
here.Example
Specifying a global identifier field
Selection
Introspection
Something like
@idField
could perhaps also be added for non-global IDs. Built-in directives may need some form of namespacing – not sure if something like@__idField
would look good, but there may be other alternatives like@@idField
).Could something like this work?
The text was updated successfully, but these errors were encountered: