KandraMigration

Base class for a single versioned CQL migration.

Define migrations as Kotlin object subclasses and register them with KandraMigrationRunner.run. Migrations are applied in ascending version order and skipped if already applied.

Never modify a migration after it has been applied to any environment. Kandra validates checksums on startup and throws io.kandra.core.exception.KandraMigrationException if a previously-applied migration's body has changed.

If a checksum mismatch is a false positive (GH #63 / ISS-062)

checksum normalizes away the most common sources of toolchain noise (see its KDoc), but it is an approximation of "did the behavior change", not a semantic diff -- a large enough compiler upgrade can still, rarely, flip a checksum for a migration whose source is byte-for- byte unchanged. If you've manually confirmed (by diffing source, not just re-reading it) that a reported mismatch is exactly this kind of false positive, the documented recovery path is to acknowledge it explicitly rather than edit the migration or its row by hand-guessing: inspect KandraMigrationRunner.history for the stored checksum, confirm the only difference is toolchain noise, and update that one row's checksum column to the new value it reports (UPDATE kandra_migrations SET checksum = ? WHERE version = ?). Never do this without confirming the migration's actual behavior is unchanged.