Support for multiple keys #12
Conversation
|
One more thing we noticed was that the |
graphene_federation/main.py
Outdated
| @@ -20,9 +20,11 @@ def build_schema(query, mutation=None, **kwargs): | |||
| return graphene.Schema(query=_get_query(schema, query), mutation=mutation, **kwargs) | |||
|
|
|||
|
|
|||
| def key(fields: str): | |||
| def key(fields: str, *args: str): | |||
There was a problem hiding this comment.
I think the more explicit and consistent way would be to use new decorator for each primary key
as in federation docs
https://www.apollographql.com/docs/apollo-server/federation/advanced-features/#multiple-primary-keys
type Product @key(fields: "upc") @key(fields: "sku") {
upc: String!
sku: String!
price: String
}
otherwise, we should make breaking changes and set fields as args:
def key(*fields: str)
Cause having *args together with fields is a bit confusing
| @@ -12,11 +12,17 @@ class FunnyText(ObjectType): | |||
| id = external(Int(required=True)) | |||
|
|
|||
|
|
|||
| @extend(fields='name') | |||
There was a problem hiding this comment.
Let's also add @extend(fields='id') to another node, to test multiple primary keys logic
Nice catch! BTW, as a solution, you can just specify fields in camelCase Anyway we can discuss it in separate issue |
this didn't work for me because it's trying to call the resolver with this name and failing, will address feedback shortly. |
jonnii
force-pushed
the
support-for-multiple-keys
branch
from
37bea5b to
75a3c43
Compare
|
@erebus1 I think this all good to go now, let me know if you have any more feedback. |
|
Cool! |
No description provided.