Interface MigrationRunOptions

Database connection config

Extra user placeholders merged into Skyway's Placeholders map. Overrides built-ins on key collision.

Path to the directory containing migration SQL files

MJ core schema (used to resolve ${mjSchema} placeholder in migrations). Defaults to '__mj'.

Target database platform. Selects the Skyway provider (@memberjunction/skyway-sqlserver vs @memberjunction/skyway-postgres). Defaults to 'sqlserver' for backward compatibility.

The app's database schema name (used as defaultSchema)

How migrations are wrapped in transactions:

• 'per-migration' (default) — each migration file runs and commits in its own transaction. Flyway's semantics, and what MJCLI's transactionMode already defaults to for mj migrate.
• 'per-run' — one transaction wraps the entire pending set (all or nothing).

Defaults to 'per-migration' because 'per-run' cannot host every valid migration set. SQL Server cannot create a table type and instantiate a variable of that type in the same transaction: the CREATE TYPE's schema-modification lock is still held while TVP instantiation — which runs in a nested system transaction that does not share the session's lock ownership — requests schema-stability on it, so the session deadlocks against itself (error 1205). On a from-zero install every migration is pending, so under 'per-run' the whole app is one transaction and no arrangement of migration files avoids it. 'per-run' remains available opt-in.

Callers relying on all-or-nothing must note that under 'per-migration' a set that fails partway leaves earlier files committed and recorded in the app's history table. Undoing an install is therefore the caller's responsibility (the install orchestrator compensates by removing the app's metadata, running its declared teardown scripts, and dropping its schema) rather than the database's.

Enable verbose output