Migrations and history

A migration is a change to the table’s structure: create a table, add a column, change a type. Pawabase plans migrations from your definition, shows you the SQL, applies them when you say so, and keeps what it needs to roll back. The principle: columns are only ever added automatically. Nothing is dropped or retyped without you reviewing it.

​

The cycle

1. You edit the definition (add a column, change a type, add an index).
2. Pawabase compares it with the real table and produces a plan.
3. You review the plan. Safe changes (a new nullable column) are plain. Risky ones are flagged Needs review.
4. You apply it. Pawabase runs the statements and records a migration.
5. If something is wrong, you roll the migration back.

​

In Studio

​

Pending migrations

When a definition differs from the table, the table’s History tab (and the Data → Tools → History page for all tables) shows Pending migration: these changes are planned from the current table and resource definition, but have not run yet. Each row shows the Table, the Change, and a Review note. A warning appears for changes that can retire, rewrite, or rebuild existing database structures. Click Apply to run it. The sidebar’s History tool shows a count of pending changes.

​

Migration history

Every schema change made through Pawabase, across all resource tables in this environment. Columns: Migration, Table, Change, Who / when, Result. From a row you can open the SQL that ran, and Roll back.

​

Kept for rollbacks

When a migration changes or removes something, the old values are kept next to the column so the change can be undone: the old values are kept next to the column until you remove them. The Kept for rollbacks card lists what is held. When you are sure, purge it to free the space; after that, that migration can’t be undone.

​

Changed outside Pawabase

If someone changed the table with SQL, Studio shows Changed outside Pawabase. You can acknowledge it (take the table as it is now and put what changed into the definition) or fix the table.

​

What each kind of change does

​

Safe patterns

​

Add a required column to a table with data

1. Add the column as nullable. Apply.
2. Backfill existing rows (an import with upsert, or an UPDATE in the SQL editor).
3. Mark it Required. Apply.

​

Rename a column

Renaming is add + copy + remove, not one step:

1. Add the new column. Apply.
2. Copy the data: UPDATE t SET new_name = old_name.
3. Update your app to use the new name.
4. Remove the old column from the definition. Review, apply.

​

Change a type

Add a new column of the new type, copy with a cast, switch the app, remove the old one. The built-in change keeps the old values for rollback, but a two-column approach lets you ship in steps without downtime.

​

Environments

Develop migrations in development, then promote the definition to staging and production. Each environment has its own database, so applying in one does not apply in another: promoting copies the definition; you still apply the migration there. Take a backup before a risky migration in production.

​

Troubleshooting