This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Last revision Both sides next revision | ||
development:database_migration_management [2015/04/24 13:08] lee [The basics of how Flyway works] |
development:database_migration_management [2015/04/24 13:08] lee [Create idempotent database migration scripts] |
||
---|---|---|---|
Line 43: | Line 43: | ||
==== Create idempotent database migration scripts ==== | ==== Create idempotent database migration scripts ==== | ||
If a script fails half way through then you don't want to have to manually drop the objects that were created. | If a script fails half way through then you don't want to have to manually drop the objects that were created. | ||
- | This can be avoided by including DDL statements to drop objects if they already exist. That way a script will clean-up previously created objects automatically when it is re-run. | + | This can be avoided by including DDL statements to drop objects if they already exist. That way a script will clean-up previously created objects automatically if it is re-run. |
==== Manually rolling back a Flyway migration ==== | ==== Manually rolling back a Flyway migration ==== | ||
It is not encouraged but it is possible to edit a database migration script and re-run it. You would need to manually delete the row containing the record of the previous execution of the script from the SCHEMA_VERSION table (and if necessary also drop any database objects that had been created). Care must be taken not to delete any other rows from the SCHEMA_VERSION table. | It is not encouraged but it is possible to edit a database migration script and re-run it. You would need to manually delete the row containing the record of the previous execution of the script from the SCHEMA_VERSION table (and if necessary also drop any database objects that had been created). Care must be taken not to delete any other rows from the SCHEMA_VERSION table. | ||