Model mixins

Posts and notes both need creation and update timestamps. Copying the same fields into every model works, but a mixin gives those shared fields a home:

mixin Timestamps {
  created_at DateTime @default(now())
  updated_at DateTime @updatedAt
}

model Post {
  use Timestamps
  id    BigInt @id
  title String
}

model Note {
  use Timestamps
  id   BigInt @id
  body String
}

Both Post and Note now have created_at and updated_at. They are still separate models with their own tables and generated APIs:

let posts = client.post().order_by_desc(Post::created_at).all().await?;
let notes = client.note().order_by_desc(Note::updated_at).all().await?;

mixin and use are RSL syntax. Timestamps is a name you choose. You can keep writing fields directly on any model that doesn't need the shared bundle.

Share the common part

A mixin can hold fields, relationships, keys, and indexes. Use it for declarations that really belong together, and leave each model's own content on that model. For example, Post's title and Note's body stay visible in the example above.

A mixin can also use another mixin:

mixin Tracked {
  use Timestamps
  version BigInt @rent.version
}

Put shared mixins in another .rsl file within the same schema directory if that makes a large schema easier to read. File order doesn't matter. The editor's Go to Definition follows use Timestamps back to its declaration.

Add permissions separately

A model mixin shares fields. A permission profile shares access rules. You can use one, both, or neither:

model Document {
  use OwnedFields
  title String
}

permissions Document {
  use PrivateOwnedResource
}

Here, OwnedFields and PrivateOwnedResource are definitions in your application. The reuse tutorial builds from timestamps to this pattern. The permission-profile tutorial explains the access rules.

Keep shared declarations predictable

Each resulting field has one definition: a local field can't silently replace a mixin's field, and two mixins can't both supply the same field. Rent reports these conflicts at the schema rather than choosing one definition for you.

Mixins apply to models and other mixins. See the schema reference for composition rules.