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.
Properties
Functions
Entry point the runner actually calls (ISS-108). keyspace is the keyspace the KandraMigrationRunner targets, or null when it uses the session's current keyspace. Defaults to delegating to up, so existing migrations are unaffected (and their checksums unchanged). Override this instead of up only if the body needs the target keyspace; when a runner targets a non-session keyspace, migration CQL must qualify its own table names (CREATE TABLE ks.users ...) because the shared session is not switched.