Jonathan Bernard
f5943a69f0
Previously we prevent the user migrating the database in either direction if there were missing or out-of-order migrations. However, going down should always be safe (assuming proper down scripts were written) and often going down is the proper way to resolve out-of-order migrations. Going down should always be done thoughtfully (it is highly likely to lead to data loss), and really should not be done in a production setting. However, in a development environment, it is not unusual to get into states where you have missing scripts. For example, if there are test scripts that apply test data to a development environment on top of the formal application schema, you may need to back out the test migrations before creating new application migrations to avoid getting into an "inconsistent state." Consider the following migrations: - 1-initial-schema - 2-add-feature-x - T1-test-user-data If you then add *3-add-feature-y*, you will be in an inconsistent state, as the expected ordering from db_migrate's point of view will be: - 1-initial-schema - 2-add-feature-x - 3-add-feature-y - T1-test-user-data With the previous behavior db_migrate refuses to do anything and you must manually back-out the test migrations before applying the new migration. With the new behavior you can easily go down to back out the test migrations automatically before going back up with the new migrations. As an aside: Another way to avoid this is to name test migrations in such a way that they stay inline with the changes they are built on top of: - 1-initial-schema - 1.1-test-user-data - 2-add-feature-x - 2.1-feature-x-test-data But sometimes the previous pattern is preferable, as it allows you to have test migrations that evolve and match the "current state of test data" rather than a developer needing to layer the contents of multiple migrations to get a clear picture of the test data. This same issue applies to non-test migrations, but db_migrate exists to solve the use-case where you generally prefer to have traversible, immutable layers that are used to manage production database schema migrations downtown.
DB Migrate
Small tool(s) to manage database migrations in various languages.
Usage
Usage:
db_migrate [options] create <migration-name>
db_migrate [options] up [<count>]
db_migrate [options] down [<count>]
db_migrate [options] init <schema-name>
db_migrate (-V | --version)
db_migrate (-h | --help)
Options:
-c --config <config-file> Use the given configuration file (defaults to
"database.properties").
-q --quiet Suppress log information.
-v --verbose Print detailed log information.
--very-verbose Print very detailed log information.
-V --version Print the tools version information.
-h --help Print this usage information.
Database Config Format
The database config is formatted as JSON. The following keys are supported by all of the implementations:
sqlDir-- Directory to store SQL files.
The following keys are supported by the Nim implementation:
connectionString--