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.
13 lines
296 B
Nim
13 lines
296 B
Nim
# Package
|
|
|
|
bin = @["db_migrate"]
|
|
version = "0.4.0"
|
|
author = "Jonathan Bernard"
|
|
description = "Simple tool to handle database migrations."
|
|
license = "BSD"
|
|
srcDir = "src/main/nim"
|
|
|
|
# Dependencies
|
|
|
|
requires: @["nim >= 2.0.0", "docopt >= 0.1.0", "db_connector"]
|