Corely.IAM.DataAccessMigrations.Cli 2.0.1

Corely IAM Database Migration CLI

Creates and migrates the Corely IAM database schema. This is the supported way to stand up the IAM tables — the library itself never applies migrations at runtime.

The tool ships both provider migration sets, so nothing beyond it needs to be referenced.

Install

dotnet tool install --global Corely.IAM.DataAccessMigrations.Cli

The command is corely-iam-db.

The tool's major version tracks the library's: CLI 2.x targets Corely.IAM 2.x. Minor and patch versions move independently, since most IAM releases add no migrations.

Configuration

Every db command takes the provider and connection string as options, falling back to environment variables:

The option wins when both are present. There is no settings file — an installed tool would have to keep one in its own install directory, shared by every repository and CI job on the machine.

# Per invocation
corely-iam-db db create -p MsSql -c "Server=(localdb)\MSSQLLocalDB;Database=CorelyIam;Trusted_Connection=True;"

# Or once per shell
export CORELY_IAM_DB_PROVIDER=MsSql
export CORELY_IAM_DB_CONNECTION="Server=(localdb)\MSSQLLocalDB;Database=CorelyIam;Trusted_Connection=True;"
corely-iam-db db create

$env:CORELY_IAM_DB_PROVIDER = "MsSql"
$env:CORELY_IAM_DB_CONNECTION = "Server=(localdb)\MSSQLLocalDB;Database=CorelyIam;Trusted_Connection=True;"
corely-iam-db db create

Commands

db status and db list take -a, --show-all to include migrations belonging to other contexts in the same database. db script takes -o, --output to write to a file and -i, --idempotent for a script that is safe to run repeatedly.

Migrations history table

IAM records its migrations in __CorelyIamMigrationsHistory rather than the default __EFMigrationsHistory, so it can share a database with your own contexts without their migration records interleaving.

A database that was migrated before this default existed has its IAM history in __EFMigrationsHistory. Either keep using it:

corely-iam-db db migrate --history-table __EFMigrationsHistory

or copy the records across once and drop the option:

-- SQL Server
SELECT * INTO __CorelyIamMigrationsHistory FROM __EFMigrationsHistory;

-- MySQL
CREATE TABLE __CorelyIamMigrationsHistory AS SELECT * FROM __EFMigrationsHistory;

That copies everything, which is what you want when IAM is the only context in the database. If it shares the database, restrict the copy to the migration ids corely-iam-db db list reports.

Run db status afterwards: every IAM migration should read as applied. If they read as pending, the copy did not land and migrating would try to recreate tables that already exist.

Examples

# First-time setup
corely-iam-db db create -p MsSql -c "<connection string>"

# Deployment script, reviewed before it runs anywhere
corely-iam-db db script -i -o deploy.sql -p MsSql

# CI or a test fixture with a container-assigned connection string
CORELY_IAM_DB_PROVIDER=MsSql CORELY_IAM_DB_CONNECTION="$CONN" corely-iam-db db create

db script needs a provider but never opens a connection, so it works offline.

Authoring migrations

Creating migrations is a development task that needs the repository, not this tool. Use the scripts at the repository root, which target both providers:

.\AddMigration.ps1 "MigrationName"
.\RemoveMigration.ps1
.\ListMigrations.ps1

Notes

• db create is safe to run against an existing database — it applies whatever is pending.
• db migrate 0 reverts all migrations but does not drop the database.
• db drop is destructive and cannot be undone.