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)Apply every Flyway migration found at the given classpath
locations to ds. Accepts a single string or a coll of strings.
Returns ds.
Apply every Flyway migration found at the given classpath `locations` to `ds`. Accepts a single string or a coll of strings. Returns `ds`.
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 |