Store Field Types

Store Field Types

Fields in a resource block use the same type system as accepts and responds with, plus additional modifiers for database mapping, primary keys, and column aliasing. This page covers the store-specific aspects. See Field Types for the complete type system.

When to use

Every resource needs at least one field (typically an id primary key). Fields define the schema of the underlying database table. Choose types that match your data semantics: text for strings, integer for whole numbers, decimal for currency, datetime for timestamps, and so on.

Syntax

resource <name>
  <field_name> as <type>, <modifiers>
  timestamps

Field declaration

Component	Description	Example
field_name	Bare identifier	email
as <type>	Type annotation	as text
Modifiers	Comma-separated flags and key-value pairs	is required, default: "draft"

Store-specific modifiers

These modifiers are available on store resource fields in addition to the standard field modifiers (is required, default).

Modifier	Description	Example
is primary_key	Marks this field as the resource’s primary key. Every resource needs exactly one.	id as uuid, is primary_key
column: "<name>"	Maps to an existing database column with a different name. Used with external databases.	ext_id as text, column: "external_id"
timestamps	Shorthand that expands to two fields: inserted_at as datetime and updated_at as datetime. Managed automatically.	timestamps

Standard modifiers (shared with accepts/responds with)

Modifier	Description	Example
is required	Field must have a value; cannot be nil	name as text, is required
default: <value>	Default value if not provided	status as text, default: "active"

Available types

Type	Description	Database type
text / string	Text value	TEXT / VARCHAR
number	Numeric value (integer or float)	NUMERIC
integer	Whole number	INTEGER / BIGINT
decimal	Precise decimal (financial, measurements)	DECIMAL / NUMERIC
boolean	True or false	BOOLEAN
uuid	UUID identifier	UUID / TEXT
date	Calendar date (no time)	DATE
datetime	Date and time (UTC)	TIMESTAMP
list(<type>)	List of values	JSONB (PostgreSQL) or JSON (SQLite)
map	Key-value map	JSONB / JSON
enum("a", "b", "c")	One of a fixed set of values	TEXT with check constraint
any	Any type (no validation)	JSONB / JSON

Examples

Common field patterns

resource product
  id as uuid, is primary_key
  name as text, is required
  description as text
  price as decimal, is required
  quantity as integer, default: 0
  in_stock as boolean, default: true
  category as text
  tags as list(text)
  metadata as map
  status as enum("draft", "active", "discontinued"), default: "draft"
  timestamps

External database with column mappings

resource customer, table: "tbl_customers"
  id as uuid, is primary_key, column: "cust_id"
  name as text, is required, column: "full_name"
  email as text, column: "email_addr"
  created_at as datetime, column: "date_created"

Column mappings tell Ash which database column each field corresponds to. The field name in your mashin code can be clean and readable while the column name matches your existing schema.

Enum fields

resource ticket
  id as uuid, is primary_key
  priority as enum("low", "medium", "high", "critical"), default: "medium"
  status as enum("open", "in_progress", "resolved", "closed"), default: "open"
  timestamps

Enum fields restrict values to a predefined set. Any create or update action that provides a value outside the set fails validation.

Governance

Field declarations are structural. They do not involve runtime governance. The governance implications come from the actions that read and write these fields:

• create and update actions validate field types and modifiers (required, default) before persisting
• policy blocks can restrict access based on field values
• All field values in create/update operations are recorded in the behavioral ledger

See also

• Field Types - Complete type system reference (shared with accepts/responds with)
• resource - Resource declarations
• create - Create actions that accept fields
• update - Update actions that modify fields
• identity - Unique constraints on field combinations