Versions

Roll back to an earlier version

Rolling back changes your live schema in Kenseme to match a past version. You can roll back the whole schema, or a single object. Both paths run a preflight check first and ask you to type the name to confirm.

In the app: Data Model › Schemas › your schema › Versions › red history icon

[screenshot]
The "Roll back to v1.2.3" dialog on its first step: the red warning, the "What will change" grid, and a warnings section with its acknowledgement checkbox.

Before you start

  • You need write access to the schema. The rollback buttons are hidden for read-only users and disabled while your organization is in read-only mode.
  • The target version must already exist. You can only roll back to a version you created earlier.
  • Only one rollback can run on a schema at a time. If another is running you see Another rollback is already running for this schema. Please wait and try again.

Warning: Rollback changes Kenseme’s design, not your database. To take a deployed database back too, generate a DOWN migration script between the two versions and run it. See Generate a migration script.

Roll back the whole schema

Step 1: Review

  1. On the Versions page, click the red history icon (Roll back whole schema to this version) on the version you want.
  2. Kenseme analyzes the rollback. The Roll back to v1.2.3 dialog opens.
  3. Read the red banner. It names the schema and the target version.
  4. Review What will change. For tables, columns, indexes, relationships, views, procedures, functions, scripts, and enums, each cell shows +added · -removed · ~modified.
  5. Read the side-data line if one appears. It tells you how many attribute values, glossary term links, and lineage rows will be soft-deleted because the objects they point at are going away.
  6. Work through the three expandable sections:
    • Blockers (red), for example relationships that would be left pointing at a removed table. You cannot continue while any blocker remains. Fix the cause in the live schema and start again.
    • Warnings (orange), for example Pipelines or star schema plans that reference the schema, or views that will be flagged invalid. Tick I understand these warnings to continue.
    • Auto-healed items (blue, collapsed), for example attribute values that will be soft-deleted. These are handled for you.
  7. Click Next: Confirm.

Step 2: Confirm

  1. Type the schema name exactly into the box. The match is case-sensitive.
  2. Leave Create a pre-rollback auto-snapshot so this rollback is recoverable (recommended) ticked. If you untick it, you must also tick I understand this rollback will be UNRECOVERABLE.
  3. Click Roll back now. Back returns you to step 1; Cancel closes the dialog without changes.

Roll back a single object

Tables, columns, views, procedures, functions, and scripts each have a Versions tab on their detail page. It lists every schema version with the object’s state in that version. A Not present badge marks versions in which the object didn’t exist.

  1. Open the object and click its Versions tab.
  2. Click Roll back to this on the version you want.
  3. Complete the same two steps as above. You type the object’s name instead of the schema’s.

Rolling back an object restores the object and everything under it (for example, a table and its columns and indexes). Anything under it that didn’t exist in the target version is soft-deleted.

Note: Rolling back a single object never takes a pre-rollback snapshot, because snapshots always cover the whole schema. If you want a safety net, create a version from the Versions page first.

Enums have no per-object rollback. Roll back the whole schema to restore an enum.

What happens next

  • A toast confirms the rollback, for example Schema rolled back to v1.2.3. Pre-rollback snapshot created as recovery point.
  • The live schema now matches the target version.
  • The pre-rollback snapshot appears at the top of the Versions list as a revision bump of your latest version, with a note starting Auto-snapshot before rollback. To undo the rollback, roll back to that snapshot.
  • Views, procedures, and functions that depended on removed objects are flagged invalid. Re-analyze them once the schema is settled.
  • Pipelines and star schema plans are not changed. Regenerate their load procedures if the tables they use were removed or changed.