Mutations Support

[dOrgJelli]

With these changes the graph build command now supports subgraph mutations.

Here's an example project setup:

subgraph.yaml

...
schema:
  file: ./schema.graphql
mutations:
  file: ./src/mutations/mutations.yaml
dataSources:
  ...

mutations.yaml

specVersion: 0.0.1
repository: https://npmjs.com/package/gravatar-mutations
schema:
  file: ./schema.graphql
resolvers:
  kind: javascript
  file: ./dist/index.js

src/mutations/schema.graphql

input Options {
  value: String!
}

type Mutation {
  someFunction(
    options: Options!
  ): EntityType
}

schema.graphql

type EntityType @entity {
  id: ID!
}

The following syntax is also supported:

subgraph.yaml

...
schema:
  file: ./schema.graphql
mutations:
  specVersion: 0.0.1
  repository: https://npmjs.com/package/gravatar-mutations
  schema:
    file: ./src/mutations/schema.graphql
  resolvers:
    kind: javascript
    file: ./src/mutations/dist/index.js
dataSources:
  ...

[Jannis]

This is looking great! Please make sure to format all files with Prettier. 😄

[Jannis]

Let's unravel this a little bit. How about this error mesage?

`\
Encountered object type '${def.name.value}. 'Mutation' is the only \
object type allowed in the mutations schema.

For mutation arguments, use 'input' types. For return values, use either \
entity types from the subgraph schema or interfaces.`

I actually think that we should allow other, non-entity types as return values here, and should allow users to define these types in the mutations schema.

The combined schema validation would have to become a little smarter to handle these. One trick could be to transform the type definitions in the mutations schema to add a @mutations directive to all of them. In the combined schema validation, we could then ignore all types with this directive.

[dOrgJelli]

Re @mutations directive: This would require changes within the graph-node to ignore these new types correct?

[dOrgJelli]

The error message has been updated with the version you wrote, thank you for simplifying the wording!

[Jannis]

I'm going to skip reviewing the tests for now, because they may change a little after the code review has been addressed. I'm glad to see so many tests though!

[dOrgJelli]

Tests have been updated.

[Jannis]

One more comment: We have an (undocumented) convention for our commit messages. The commit subject is expected to start with the "module" or scope that the changes are made against. Would it be possible to follow this convention in this PR as well?

Check some of the more recent commit messages for reference:

travis: Upgrade the Linux dist and disable the `graph auth` test
codegen: Fix contract call codegen for small uints
compiler: Only compile identical mappings once
compiler: Cache uploaded files using SHA1 instead of paths (#393)
commands/init: Add POA Core support
scaffold: Bump graph-ts to 0.16.0
NPM: Add release:patch and release:minor commands
examples/example-subgraph: Bump graph-cli and graph-ts
tests/cli/validation: Add tests for network validation
commands: Fix spacing
commands: Use the correct exit codes on deploy cmd
manifest-schema, manifest: Add startBlock field, validation for BigInt
compiler: Improve error message for not found `node_modules`
compiler: Improve loop to find `node_modules`
compiler: Increase number of ancestor directories checked for libs
compiler: Check directories above for libs
compiler: Prefer `print.error` over `console.log`
compiler: Do not assume the source dir is the working dir
examples, scaffold: Update to graph-ts 0.15.0
example-subgraph: Update graph-ts

[dOrgJelli]

@Jannis in order to follow the commit message standard, I can recreate this PR from a new branch where I commit the file changes one by one. Does that sound like a good choice to you?

[Jannis]

@dOrgJelli Why not rebase and reword all commit messages as you go?

[dOrgJelli]

@Jannis commit messages have been updated

[azf20]

Closing as stale, but definitely interested in reigniting mutation discussions!