Problem
When DataProviderMigrate reports an unexpected result, there is currently no CLI-supported way to see what it inspected, diffed, filtered, or applied.
The current help output exposes these migrate options only:
--schema
--output
--provider
--allow-destructive
--phase
There is no --verbose, --log-level, --debug, or equivalent option.
Setting common .NET logging environment variables such as Logging__LogLevel__Default=Trace did not produce additional diagnostics. The CLI still printed only the normal summary.
Required behavior
Add explicit logging controls to the migration CLI, for example:
DataProviderMigrate migrate \
--schema migrations/schema.yaml \
--output "$PG_URL" \
--provider postgres \
--log-level trace
or:
Logging should expose
At debug/trace level, the CLI should print enough information to diagnose schema drift and diff bugs without attaching a debugger:
- which schema file was loaded and parsed
- all tables discovered in YAML
- live database objects inspected per table
- desired vs actual object summaries
- generated diff operations before phase/destructive filtering
- operations removed by
--phase
- operations removed because
--allow-destructive is absent
- SQL or operation descriptions that will be applied, with secrets redacted
- post-apply verification results once that verification exists
Security requirement
Connection strings and credentials must be redacted in logs by default. It is fine to show host/database/user, but passwords and tokens must never be printed in full.
Why this matters
During a production migration incident, the tool reported Schema is up to date even though a declared unique constraint was missing from PostgreSQL. Without verbose logging, there was no way to tell whether the YAML parser ignored the uniqueConstraints block, the inspector missed live constraints, the diff skipped unique constraints, or operation application failed.
Operators need first-class CLI diagnostics to understand what the migrator is doing.
Problem
When
DataProviderMigratereports an unexpected result, there is currently no CLI-supported way to see what it inspected, diffed, filtered, or applied.The current help output exposes these migrate options only:
There is no
--verbose,--log-level,--debug, or equivalent option.Setting common .NET logging environment variables such as
Logging__LogLevel__Default=Tracedid not produce additional diagnostics. The CLI still printed only the normal summary.Required behavior
Add explicit logging controls to the migration CLI, for example:
or:
Logging should expose
At debug/trace level, the CLI should print enough information to diagnose schema drift and diff bugs without attaching a debugger:
--phase--allow-destructiveis absentSecurity requirement
Connection strings and credentials must be redacted in logs by default. It is fine to show host/database/user, but passwords and tokens must never be printed in full.
Why this matters
During a production migration incident, the tool reported
Schema is up to dateeven though a declared unique constraint was missing from PostgreSQL. Without verbose logging, there was no way to tell whether the YAML parser ignored theuniqueConstraintsblock, the inspector missed live constraints, the diff skipped unique constraints, or operation application failed.Operators need first-class CLI diagnostics to understand what the migrator is doing.