Docs
Risk levels
Every change gets one of three levels and a reason. The level is about what can happen to data that’s already in your database.
Safe
Nothing existing is touched. Adding a table or an empty column is safe.
Caution
Works, but can fail on existing data, lock a busy table for a while, or break code that uses old names.
Destructive
Can delete or cut off data that’s there now. Read these twice.
Everything JillionDB checks
These are the exact reasons you’ll see in a review.
Safe
Adding a table
New table; nothing existing is touched.
Safe
Adding an optional column
Adds an empty column; existing rows are untouched.
Safe
Making a type longer, or adding options
Allows longer values or more options; existing data is untouched.
Safe
Making a column optional
Allows empty values; nothing existing changes.
Safe
Changing a default value
Affects new rows only.
Safe
Changing a comment
Documentation only.
Safe
A relationship removed along with its table
Removed along with its table.
Safe
Renaming generated index and key names
Keeps generated names in step with the new names.
Caution
Renaming a table or column
Code that uses the old name stops working until it’s updated.
Caution
Adding a required column with no default
Fails if the table already has rows, because they have no value for it.
Caution
Adding a column that fills every row
Fills every existing row, which rewrites the table and locks it while it runs.
Caution
Changing to a larger type
Rewrites the table to the larger type and locks it while it runs.
Caution
Switching between times with and without a time zone
Existing times are converted using the server’s time zone.
Caution
Changing a database-specific type
Changes the database-specific type; check that existing values convert.
Caution
Making a column required
Fails if any existing row is empty.
Caution
Changing how new ids are made
Changes how new ids are made; they can collide with existing ones.
Caution
Adding a no-duplicates rule
Fails if existing rows already have duplicates.
Caution
Removing a no-duplicates rule
Duplicates become possible.
Caution
Changing the primary key
Fails on duplicates, and links to this table may need updating.
Caution
Adding an index
Locks writes to the table while the index builds on large tables.
Caution
Removing an index
Queries that relied on it may get slower.
Caution
Adding a relationship
Checks every existing row and fails if any don’t match.
Caution
Removing a relationship
The database stops checking these values.
Caution
Adding a check rule
Fails if any existing row breaks the rule.
Caution
Removing a check rule
The database stops enforcing this rule.
Caution
Changing table options
May rebuild the table.
Caution
Changes SQLite can only make by rebuilding the table
SQLite copies the table into a new one to make these changes.
Destructive
Deleting a table
Deletes the table and every row in it.
Destructive
Deleting a column
Deletes the column and its data.
Destructive
Making a type shorter or smaller
Values that don’t fit are cut off or make the change fail.
Destructive
Removing options from a list
Rows that use … make the change fail.
Destructive
Changing to a different kind of type
Converting existing values can fail or lose data.
Notes on the whole migration
Caution
MySQL migrations with several steps
MySQL can’t undo schema changes halfway: if a step fails, the earlier steps stay applied.
Caution
Rolling back a destructive change
Rolling back recreates dropped tables and columns, but not their data.