Seeds

A seed creates data for development by calling your app's own actions, so validation, lifecycle and policy apply to it. Each seed is a file in database/seeds/.

database/seeds/local_demo.jadpo:

/// A user with a few todos, for local development.seed {    var alice: User = attempt planning.register_user("alice@example.com")    attempt planning.create_todo(alice.id, "Buy milk")    attempt planning.create_todo(alice.id, "Book dentist")}

A seed is named by its file: seed { } in local_demo.jadpo is local_demo. It is checked like a test, and its calls run as a test's do (Calls with no caller): one that passes a caller runs as them, under policy, and one that passes none runs without it, which is how a seed makes the first user who holds a role.

jadpo seed <name> runs one (jadpo seed). It refuses a production database: data production needs is a migration backfill. A production database is any that isn't on this machine: every server the store's address names must be a Unix socket, localhost, 127.0.0.1 or ::1, the ones PostgreSQL over TLS also treats as this machine. Nothing is run against any store until every store passes (seed.production_refused).

A seed runs as a request does, at one time read from the clock and with the machine's randomness, so each run makes new identities. Each action it calls commits on its own, so a seed that stops at a failure or a fault keeps what its earlier calls committed (seed.failed). Mail lands in the dev inbox and provider calls are faked, as under jadpo dev, and what its actions emit is delivered before the command ends.