Migration Tab

The Migration tab compares Entity definitions with database schemas, creates migration files, and applies migrations to one or more databases.

​

Compare and generate

The baseline DB selector only includes connections where every migration is applied. Sonamu compares that database’s schema with the Entity definitions and previews the changes and generated code.

1. Select a baseline database.
2. Use Expand all to review the generated code when needed.
3. Select Generate migrations to create the files.

After files are generated, Pending state is refreshed for every database.

​

Migration status

Rows are migration files and columns are database connections. Each cell shows APPLIED or PENDING. Connections load independently, so a slow or failed database does not block other columns.

• Select an execution target by clicking its column header or cells.
• Enable Details to show the host, database, remote marker, and per-column refresh action.
• Select an Error badge to inspect the server error.

​

Apply latest

Apply latest runs knex.migrate.latest() for each selected database in order. Files applied to one database remain in one Knex batch. The execution dialog has these stages:

1. Review the targets and Pending files, and choose whether to run Shadow validation.
2. Approval requests Slack approval for configured remote targets and checks it every two seconds.
3. Apply displays per-file progress and per-database completion.

When Shadow validation is enabled, a dotted Shadow card is shown at the top of the target list. Once Apply starts, the same card shows real validation progress and its result. Sonamu only starts the target databases after Shadow succeeds. If the browser connection drops, a migration already started on the server may continue. Do not run it again automatically; refresh connection status to verify the result.

​

Rollback

Rollback ignores migration-file row selection and rolls back the entire latest Knex batch on each selected database. Knex runs the batch’s down() functions in reverse order. Because this is destructive, the first click only arms the Rollback button and changes its confirmation text. The second click starts the operation. If a file fails, execution stops at that file. The rollback transaction is canceled, so the database may appear unchanged. Rollbacks run from the latest migration backward, so execution cannot continue to the next rollback after a failure in the middle.

​

Next steps