Java.DBMigrationTools.How are migrations tracked?

✅ Short Answer

Migrations are tracked using a special table in your database where the tool records every changeset or script it has applied — so it knows what’s already been done and what’s still pending.

---

🔎 Liquibase Tracking

Liquibase uses two special tables:

Table Name	Purpose
DATABASECHANGELOG	Tracks all applied changesets: id, author, checksum, timestamp…
DATABASECHANGELOGLOCK	Ensures only one Liquibase instance runs at a time (lock flag)

✅ When you run liquibase update, it checks DATABASECHANGELOG to see:

• Which id + author combinations have already been run
• Whether the file’s checksum changed (to detect unauthorized edits)

Each applied changeset gets one row in DATABASECHANGELOG.

---

✅ Columns in DATABASECHANGELOG include:

• ID — the unique changeset ID
• AUTHOR — who authored the change
• FILENAME — changelog file
• DATEEXECUTED — timestamp
• MD5SUM — to detect changes
• ORDEREXECUTED — order of application
• TAG — optional release label

🔎 Flyway Tracking

Flyway uses a single table called:

Table Name	Purpose
flyway_schema_history	Tracks all versioned migration files that have been applied

✅ It records:

• Version (e.g., 1, 2.1)
• Description (from filename)
• Script name (e.g., V1__create_users.sql)
• Checksum for file integrity
• Success flag (false if the migration failed)

---

🔒 Locking & Safety

Both tools:

• Use a locking mechanism to prevent concurrent migrations
• Check checksums → if someone modifies a file after it’s been applied, you get a validation error (unless you force it)

📌 Key Takeaways

✅ Migration tools record applied changes in a special DB table (DATABASECHANGELOG or flyway_schema_history)
✅ This ensures:

• Migrations are applied once
• No changes are skipped
• Modified scripts trigger checksum errors

✅ These tables are part of the DB itself — portable, visible, and auditable.