Flyway-backed schema migration runner.
Lives in the SQLite extension because:
flyway-database-nc-sqlite)
is required to recognize jdbc:sqlite: URLs - already
declared in this extension's deps.edn.flyway-core; making it a per-backend dep keeps the root
package free of the migration toolchain.migrate! from
com.blockether.vis.sdk, but it had exactly one caller
Public API:
(migrate! datasource locations) - apply every Flyway
migration found at the given classpath locations to the
supplied DataSource. Returns the datasource for thread-style
chaining.
:baseline-on-migrate true so existing databases without a
flyway_schema_history table get one on first run. :mixed true
so SQL files with mixed transactional + DDL statements work under
SQLite.
GraalVM native-image note: Flyway discovers migrations by LISTING the
classpath location directory, which native-image does not support (it can
getResource a specific file but not enumerate a dir). So build.clj writes
an _index.edn of filenames next to each migration dir, and here we feed
Flyway an explicit ResourceProvider built from those exact paths. On the
JVM (no index) we fall back to Flyway's normal location scanning.
Flyway-backed schema migration runner.
Lives in the SQLite extension because:
1. The dialect-specific Flyway driver (`flyway-database-nc-sqlite`)
is required to recognize `jdbc:sqlite:` URLs - already
declared in this extension's deps.edn.
2. Flyway is the only backend-side concern using
`flyway-core`; making it a per-backend dep keeps the root
package free of the migration toolchain.
3. The previous arrangement shipped a generic `migrate!` from
`com.blockether.vis.sdk`, but it had exactly one caller
- this extension. Other backends will ship their own
migration entry point in their own jar.
Public API:
`(migrate! datasource locations)` - apply every Flyway
migration found at the given classpath `locations` to the
supplied `DataSource`. Returns the datasource for thread-style
chaining.
`:baseline-on-migrate true` so existing databases without a
`flyway_schema_history` table get one on first run. `:mixed true`
so SQL files with mixed transactional + DDL statements work under
SQLite.
GraalVM native-image note: Flyway discovers migrations by LISTING the
classpath location directory, which native-image does not support (it can
`getResource` a specific file but not enumerate a dir). So `build.clj` writes
an `_index.edn` of filenames next to each migration dir, and here we feed
Flyway an explicit `ResourceProvider` built from those exact paths. On the
JVM (no index) we fall back to Flyway's normal location scanning.(migrate! ds locations)Install the single canonical V1 schema.
Applied checksum drift and history left by migrations later consolidated
into V1 self-heal through Flyway repair, then migration is retried. Repair
changes only flyway_schema_history; persisted Vis rows and schema objects
are preserved.
Install the single canonical V1 schema. Applied checksum drift and history left by migrations later consolidated into V1 self-heal through Flyway `repair`, then migration is retried. Repair changes only `flyway_schema_history`; persisted Vis rows and schema objects are preserved.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |