Expand description
Seed data: an app’s seed/ directory, loaded into the database.
A seed directory holds one file per resource, named after it —
seed/organization.toml, seed/user.toml, seed/product.csv — whose rows
become that resource’s rows. It is the fixture an app starts life with: an
administrator who can sign in, the organisation they administer, and enough
underneath for the dashboard to have something to show.
TOML is the primary format, because it is the format the app is already written in — a seed file looks like the resource beside it:
[[row]]
id = "acme"
name = "Acme, Inc."
slug = "acme"CSV is accepted for the same job at a hundred rows, where a header line and
a column per field says it better than a hundred [[row]] headers — and
because it is what a spreadsheet or a COPY … TO exports.
Three things make either enough, without a migration format or a script per app:
- Aliases instead of UUIDs. Anywhere an id is expected — the
idcolumn, or anyreferencefield — a value that is not a UUID is taken as a name and hashed into one (uuid_for).acmemeans the same row in every file, soseed/membership.tomlcan sayorganization_id = "acme"without anyone minting a UUID by hand. - Idempotence. Because those ids are derived rather than random,
inserting is
ON CONFLICT DO NOTHING: seeding twice inserts once, and a seed file that grew a row since the last run adds only that row. Rows already present are never overwritten — someone who edited the fixture in the dashboard keeps their edit. - Passwords. A
passwordcolumn on a resource that declares one (AuthSpec) is hashed into the password field, so the seeded administrator can actually sign in and the file stays readable.
Seeding runs in dependency order, so a file may reference rows from a file it is listed before.
Structs§
- File
Report - What one seed file did.
- Report
- What a whole
seed/directory did.