update
update
An update action on a store resource. Defines how existing records are modified, which fields can be changed, what validations run before the update, and what changes apply during the operation. Compiles to an Ash Framework update action at runtime.
When to use
Use update when you need to:
- Modify specific fields on an existing record
- Restrict which fields can be changed in a given operation
- Validate new values before persisting (e.g., status transitions, range checks)
- Apply computed side effects during an update (e.g., update a
modified_byfield)
Define separate named update actions for distinct operations on the same resource. For example, a ticket resource might have update assign and update close as separate actions that accept different fields and run different validations.
Syntax
resource <resource_name> update <action_name> accept: [<field1>, <field2>, ...] validate <rule> change <function>Parameters
| Parameter | Required | Description |
|---|---|---|
action_name | Yes | Bare identifier naming this action. Multiple update actions can exist on a single resource. |
accept | No | List of field names that this action can modify. If omitted, all non-primary-key fields are modifiable. |
validate | No | Validation rule applied before update. Can appear multiple times. |
change | No | Mutation function applied during update. Can appear multiple times. |
Examples
Simple field update
resource article id as uuid, is primary_key title as text, is required body as text status as text, default: "draft" timestamps
update edit accept: [title, body]
update publish accept: [status] validate compare(status, :eq, "published")The edit action can only change title and body. The publish action can only set status, and it validates that the value is "published".
Update with validation and changes
resource order id as uuid, is primary_key status as text, is required shipped_at as datetime cancelled_at as datetime timestamps
update ship accept: [status] validate compare(status, :eq, "shipped") change set_attribute(shipped_at, now())
update cancel accept: [status] validate compare(status, :eq, "cancelled") change set_attribute(cancelled_at, now())Narrow update for a single field
resource user id as uuid, is primary_key email as text, is required display_name as text role as text, default: "member" timestamps
update change_role accept: [role]
update update_profile accept: [display_name, email] validate format(email, ~r/@/)Splitting updates into named actions gives you fine-grained governance. An admin policy might allow change_role but not update_profile, or vice versa.
Governance
Update actions are governed effects. When a machine executes an update action:
- The governance interpreter checks the
dbcapability - The action is subject to any
policyblocks on the resource - The operation is recorded in the behavioral ledger with the action name, changed fields, and previous values
- The machine’s
ensures > permissionssection can restrict or require approval for data modifications
Update actions on sensitive fields (e.g., roles, permissions, financial data) should have explicit policies.
Translations
| Language | Keyword |
|---|---|
| English | update |
| Spanish | actualizar |
| French | modifier |
| German | aktualisieren |
| Japanese | 更新 |
| Chinese | 更新 |
| Korean | 수정 |