33.6 Mutations

With allowMutations on, every exposed type that can be created gets three fields on Mutation:

type Mutation {
  createEvent(input: EventInput!): EventNode
  updateEvent(id: ID!, input: EventInput!): Event
  deleteEvent(id: ID!): Boolean!
}

input EventInput { price: Decimal  starts: DateTime  status: EventStatus  title: String  venue: ID }

Types marked readOnly get none, which is why there is no createVenue here, and neither do interfaces that a class implements. The input has the fields that the table in §33.3 gives a mutation input, so no files.

mutation NewEvent($venue: ID!) {
  createEvent(input: { title: "Late show", price: 250, status: Published,
                       starts: "2026-12-01T21:00:00Z", venue: $venue }) {
    id
    title
    venue { name }
  }
}

create inserts a node with a new id. Properties the input leaves out get the type's default values. The new node is read back, so the selection can follow its relations.
update changes only the fields the input gives. null sets a field back to its default value. A "many" relation field replaces the whole set of related nodes, and null or [] removes them all. An id that no node has gives null with an error.
delete returns true, or false when no node has the id.

mutation {
  updateEvent(id: "7e51b1dd-…", input: { price: 300, status: SoldOut }) { title price status }
  deleteEvent(id: "1459bd5a-…")
}

Relations and references take the related node's id. A relation is set, not added to: giving an event a new venue moves it from its old one.

Each mutation field is one transaction, run in the order written. Mutations go through the NodeStore, so transaction plugins (§15) see them; a code-first endpoint needs TransactionExecutor for that (§33.9). The datamodel's validation rules (§3) apply, and a rejected change becomes an error on its field. Files cannot be set through GraphQL: upload them as described in §17.

An endpoint that allows mutations without API keys lets anyone who can reach its url change data.