-
-
Notifications
You must be signed in to change notification settings - Fork 895
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
[GraphQL] Fix type for subresource #1702
[GraphQL] Fix type for subresource #1702
Conversation
1f980ff
to
b55fd04
Compare
Thanks @alanpoulain |
Hi, I understand your choice and difficulties to implement nested mutations. But i find this rather sad. Nested mutations are a solution to solve multiple HTTP call problems from client. A project like GraphCool has choose to implement this feature in 2016/10: https://blog.graph.cool/improving-dx-with-nested-mutations-698c508339ca Hope it will exists one day in api-platform |
Something like batch operations may be more suitable for this particular issue, see #1645 |
i have to investigate on batch operations, but to my mind batch are for recurrent operations of the same kind, here operations can be over different object. I'll give it a try (if i find enough documentation about it :) |
* Add a depth variable in SchemaBuilder * Pagination should not be used for input * String type (IRI) if depth > 0 (= subresource) for input * Add a test for a mutation with a subresource
Nested mutations are not a part of the specification. See:
Moreover, it would be laborious to implement it. We would have to change the behavior of the ItemNormalizer and we would have to move the validation/access control of the resolver elsewhere to be reused in the normalizer.
Therefore, it seems a better solution to force IRIs for subresources in mutations.
This PR also fixes an issue with input types: pagination should not be used for them.