Data hygiene

Pylon’s data-layer automation is deliberately small and mostly automatic. Two built-in plugins wire themselves from your schema (you never name them in a config block). The SDK adds a few field-level and entity-level helpers. Everything else (cascades, slugs, derived fields, versioning) is a server function or a policy, not a plugin.

`tenant_scope`

Row-level multi-tenancy. It is automatic. The signal is a tenantId field on the entity. No config entry.

import { entity, field } from "@pylonsync/sdk";

export const Project = entity("Project", {
  tenantId: field.string(),   // ← presence of this field turns on scoping
  name:     field.string(),
});

Once an entity has a tenantId (or tenant_id) field:

Inserts auto-fill tenantId = auth.tenantId when the caller does not provide it. They reject a write whose tenantId does not match the caller’s. You cannot insert into another tenant.
Reads / updates / deletes are scoped to the caller’s tenant.
Admin contexts bypass scoping on writes. On reads, an admin with no active tenant bypasses scoping; an admin with an active tenant is scoped to that tenant.

This makes tenant isolation the default, not a where clause you must remember on every query. In your own query/mutation handlers you still have auth.tenantId to scope further.

`owner_stamp`

Per-row ownership. It is automatic. The signal is field.X().owner() on the field.

export const Listing = entity("Listing", {
  sellerId: field.string().owner(),   // ← stamped from the session on insert
  title:    field.string(),
});

On insert the runtime overwrites sellerId with auth.userId from the session. It rejects any client attempt to set a different user. This makes optimistic local-first writes safe for owned data. The client inserts with its own id for an instant local render. The server validates the owner from the session. Pair it with a policy like allowUpdate: "data.sellerId == auth.userId".

Schema behaviors

behaviors([...]) on the entity builder run field-injection helpers before the schema is registered. Two ship today:

import { e, field, timestamps, softDelete } from "@pylonsync/sdk";

export const Post = e.entity("Post", {
  title: field.string(),
  body:  field.string(),
}).behaviors([timestamps, softDelete]);

Behavior	Adds
`timestamps`	`createdAt` + `updatedAt` datetime fields (marked `defaultNow()`)
`softDelete`	a `deletedAt` datetime field

Behaviors mutate the EntityDefinition’s fields, so the rest of the framework (storage, sync, policies) treats the injected columns as ordinary columns.

Behaviors add the columns. The defaultNow() marker drives automatic value-stamping, which is not fully wired yet. Until it ships, set the values in your function handler (or on the client). The columns persist normally. softDelete adds the deletedAt column. The DELETE-sets-deletedAt and list-filtering semantics are app-driven for now (filter deletedAt == null in your query).

Field-level constraints & defaults

The field builder is the real “validation” surface. Pylon records it in the manifest. The runtime and codegen enforce it:

export const User = entity("User", {
  email:     field.string().unique(),
  role:      field.enum(["member", "admin"]),   // constrained set
  bio:       field.string().optional(),
  createdAt: field.datetime().defaultNow(),
  ownerId:   field.string().owner(),
});

Helper	Effect
`.unique()`	Unique index; duplicate inserts rejected
`.optional()`	Field may be omitted / null
`field.enum([...])`	Value must be one of the listed strings
`.default(v)` / `.defaultNow()`	Insert-time default value
`.owner()`	Auth-stamped ownership (see `owner_stamp`)

For richer validation (length limits, regex, cross-field rules), do the check in a mutation handler before writing, and gate access with policies.

Where other data features live

Pylon implements these features through fields, functions, policies, or auth, not configurable plugins:

Was documented as	Reality
`validation`	Field constraints (above) + checks in your `mutation` handler
`slugify`	Compute the slug in your handler / a `field.string().default(...)`
`computed`	Derive the value in your `mutation` handler before writing
`cascade`	Delete children explicitly in a `mutation` (runs in one transaction)
`versioning`	Write snapshot rows from an `after`-write step in a function
`organizations`	Real framework feature — `Org`/`OrgMember` + `/api/auth/orgs/*`. See Auth → Organizations

Full-text search

You configure search per-entity, not as a data plugin. See Search & AI.

Get started

Core concepts

SSR

Auth

Plugins

Clients

Operations

Compare

Migrate

Data hygiene

`tenant_scope`

`owner_stamp`

Schema behaviors

Field-level constraints & defaults

Where other data features live

Full-text search

​tenant_scope

​owner_stamp

​Schema behaviors

​Field-level constraints & defaults

​Where other data features live

​Full-text search

`tenant_scope`

`owner_stamp`

Schema behaviors

Field-level constraints & defaults

Where other data features live

Full-text search