MustEraseOnValidationError option is provided specifically for this use case.Yes! Evolve will use the session level lock of your database to coordinate the migrations on multiple nodes. This prevents two distinct Evolve executions from running an Evolve command on the same database at the same time.
Yes! Sometimes a hotfix is quickly applied in production without a proper Evolve migration. To ensure consistency across all environments, a migration matching those changes must be added to version control but skip in production. Use the option SkipNextMigrations to fix this issue.
Yes! By default each migration script is executed in a separate database transaction. But you can either wrap all your migrations in a single transaction using the option TransactionMode with the value CommitAll in a “all or nothing” mode, or disable transaction for one specific script writing – evolve-tx-off at the beginning of the file.
Yes! Sometimes it is usefull to run Evolve and trigger a rollback without error after the last successful script. That way upgrades can be tested against an existing database prior to doing the real thing. Keep in mind that all databases do not support DDL instructions in transaction. In this case Evolve won’t be able to perform a clean rollback. That is why it is absolutely not recommended to use this option with MySQL/MariaDB, CockroachDB and Cassandra.
To run Evolve in a dry run mode, use the option TransactionMode with the value RollbackAll
Yes! Evolve info command displays the details and status information about all past and future migrations.