migrations

Overview ¶

Package migrations supplies the work queue table's DDL, rendered for a table prefix.

The platform deliberately does not ship a numbered migration file. Migration files are numbered globally per consumer, so a platform-owned number would collide with the consumer's own the moment either side added one. The version is therefore always the consumer's to choose.

If you already run database/migrate, hand SQL to WithGeneratedMigration and the table is created by your normal migration run — no DDL copied into your repository, nothing to keep in sync as this package evolves:

ddl, err := migrations.SQL(workqueue.DefaultTablePrefix)
// ...
m, err := migrate.New(dialect.Postgres, myMigrations,
	migrate.WithGeneratedMigration(41, "create_work_queue_tables", ddl),
)

Statements is the same DDL split into individually executable statements, for callers running it some other way — a different migration tool, or a test that just wants the table.

One table holds every logical queue: workqueue.Config.Name is the leading column of its primary key, so a second queue needs a second Config, not a second migration.

Postgres only, like the package it serves. Statements and SQL take a dialect anyway, and reject anything else, so a caller wiring this into a dialect-parameterized migration run gets an error naming the dialect rather than a schema that silently renders empty.