Omnigraph
Mutations

Update

Change property values on existing nodes and edges.

The update operation changes property values on nodes or edges that match a where predicate. Updates are validated against the schema before they commit.

Basic syntax

An update has three parts: the target type, a set block with the new values, and a where clause that selects which rows to change.

query complete_task($slug: String) {
    update Task set {
        status: "completed"
    }
    where slug = $slug
}
omnigraph change --uri ./my-graph \
    --query mutations.gq \
    --name complete_task \
    --params '{"slug": "auth"}'

Or via the HTTP API:

curl -X POST http://localhost:8080/change \
    -H "Content-Type: application/json" \
    -d '{
        "query_source": "query complete_task($slug: String) { update Task set { status: \"completed\" } where slug = $slug }",
        "query_name": "complete_task",
        "params": {"slug": "auth"},
        "branch": "main"
    }'

Updating multiple properties

The set block accepts any number of properties. All listed properties are updated atomically in a single transaction:

query reassign_task($slug: String, $new_title: String, $new_status: String) {
    update Task set {
        title: $new_title,
        status: $new_status
    }
    where slug = $slug
}

Properties not listed in set are left unchanged.

Where clause operators

The where clause supports the following comparison operators:

OperatorMeaning
=Equal
!=Not equal
<Less than
>Greater than
<=Less than or equal
>=Greater than or equal

Examples:

query bump_ages() {
    update Person set { age: 0 }
    where age < 0
}
query clear_old_bios($cutoff: Date) {
    update Person set { bio: null }
    where created_at < $cutoff
}

One where predicate per update

Each update operation takes exactly one where predicate. To filter on multiple conditions, select the relevant keys with a read query first and then issue narrower updates.

query complete_task($slug: String) {
    update Task set { status: "completed" }
    where slug = $slug
}

Key properties are immutable

Properties annotated with @key cannot be changed after insertion. Attempting to include a @key property in a set block produces a compile-time error:

node Task {
    slug: String @key
    title: String @index
    status: enum(pending, in_progress, completed)
}
# This will fail at compile time:
query rename_task($slug: String, $new_slug: String) {
    update Task set { slug: $new_slug }
    where slug = $slug
}

To change a key value, delete the old node and insert a new one.

Updating edge properties

Edges with properties can be updated the same way. Because updates only support one predicate, the chosen property should uniquely or narrowly identify the rows you want to change.

query update_since_for_source($person: String, $date: Date) {
    update Knows set { since: $date }
    where from = $person
}

Edge endpoints are exposed as the reserved fields from and to.

Transactional guarantees

If any row fails validation during an update — for example, setting a value outside a @range constraint or violating a @unique constraint — the entire update is rolled back. Either all matching rows are updated or none are.

On this page