Update

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 ./my-graph \
    --query mutations.gq \
    --name complete_task \
    --params '{"slug": "auth"}'

Or via the HTTP API:

curl -X POST http://localhost:4000/change \
    -H "Content-Type: application/json" \
    -d '{
        "uri": "./my-graph",
        "query": "mutations.gq",
        "name": "complete_task",
        "params": {"slug": "auth"}
    }'

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:

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, use separate named mutations or restructure your data model so a single property identifies the target rows.

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

If you need to update rows matching a complex condition, select the relevant keys with a read query first, then issue individual updates.

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. Use src and dst in the where clause to target a specific edge:

query update_since($person_a: String, $person_b: String, $date: Date) {
    update Knows set { since: $date }
    where src = $person_a
}

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.