Opinions

Every piece of software encodes certain opinions. These are the primary opinions that are manifest in the design of dotMigrator.

Schema comparison tools aren't enough

Two problems:

1. avoiding data loss
2. different migration scripts for different targets

SQL is the DSL

Instead of inventing a fluent interface or other DSL to describe the data structure, SQL is already a complete language for making the changes needed in a SQL database

SQL isn't always enough

Sometimes data structure changes mean that data needs to be re-processed in some way through application code which can't easily be done in SQL.

Or even if it can be done in SQL, it would mean re-writing code that already exists in the application code

Relational databases aren't the only thing

Other data storage systems such as document databases, or maybe even filesystems hold data structures that may need to be declared up-front, or at least contain data whose "shape" needs to change during application upgrades.

Data structure changes are source code

... and should be in source control with the application code. It should be possible to compare tagged releases and see a textual representation of the data structure changes between them.

Setting up a development environment should be easy

Ideally, the steps are 1) install an appropriate IDE, 2) retrieve source code, 3) build, 4) run. Therefore, dotMigrator should be easy to integrate into the project's Build and/or run steps.

Rollback is rarely realistic

Transactions don't always work

Some migrations can't be done as part of a transaction simply due to database limitations. Sometimes the amount of data that needs to change is too large to effectively manage in a single transaction.

Minimizing application downtime is important

If possible, migrations that affect a large amount of data should be written so that they can run while the application remains online. The application would be updated to work simultaneously with both the pre- and post-migrated data. Then the migration runs "online" until all the data can be migrated. Then the application could be updated again to work with only the post-migrated data.

Repeatability is critical

You have pre-production environments for development, testing and verification. Don't jeopardize your production release by deploying differently than you did in your testing/verification environment. Once a data store is under management with dotMigrator, do not make data structure changes outside of dotMigrator.

If you have multiple production instances, (i.e. for different customers), this is even more important.

Even if you don't have multiple environments or instances, each developer should have a separate instance and they need to keep their own up-to-date with each other.

Branching in source control is o.k.

... but it's not o.k. in a single persistent data store. Your production database evolves linearly even if development is done concurrently in separate branches. Merging data structure changes in source control should not be a hard thing to do. This is why migrations are discovered and sequenced by their name and there aren't separate manifest files that would need to be merged.