REHEARSAL REPORT / example.db

Ready for a closer look.

A migration run against a disposable snapshot.
The source database was opened read-only. No changes were applied to it.

RESULTPassed

MIGRATIONS RUN02

OBJECTS CHANGED04

POST-RUN CHECKSPassed

Execution plan

ORDER AS SUPPLIED

#	MIGRATION	STATE	STATEMENTS	ROW WRITES*
01	001_due_dates.sql	rehearsed	2	0
02	002_activity.sql	rehearsed	3	2

Schema & row counts

BEFORE / AFTER

index:tasks_by_project

added

Rows: — → —

--- before
+++ after
@@ -0,0 +1 @@
+CREATE INDEX tasks_by_project ON tasks(project_id, state)

table:activity

added

Rows: — → 1

--- before
+++ after
@@ -0,0 +1,6 @@
+CREATE TABLE activity (
+  id INTEGER PRIMARY KEY,
+  task_id INTEGER NOT NULL REFERENCES tasks(id),
+  previous_state TEXT NOT NULL,
+  next_state TEXT NOT NULL
+)

table:tasks

changed

Rows: 3 → 3

--- before
+++ after
@@ -3,4 +3,4 @@
   project_id INTEGER NOT NULL REFERENCES projects(id),
   title TEXT NOT NULL,
   state TEXT NOT NULL DEFAULT 'open'
-)
+, due_date TEXT)

trigger:record_task_state

added

Rows: — → —

--- before
+++ after
@@ -0,0 +1,6 @@
+CREATE TRIGGER record_task_state AFTER UPDATE OF state ON tasks
+WHEN OLD.state <> NEW.state
+BEGIN
+  INSERT INTO activity(task_id, previous_state, next_state)
+  VALUES (NEW.id, OLD.state, NEW.state);
+END

What was checked

SQLite integrity and foreign-key checks before and after the rehearsal. Failed batches roll back as one transaction. Removed tables, missing column names and falling row counts require review. Column renames also request review.

What this does not prove

Row counts do not detect rewritten values. This is not a deployment, a production lock benchmark, or a hostile-SQL sandbox. *Row writes include trigger effects and count writes, not distinct rows.