Reputation: 11327
Say I have 3 commits (each one with new migrations added):
Production database is at v1
and my development database is at v3
.
I want to generate an SQL script which will upgrade the production database to v3
.
The only way I know how to do so is to rollback development database to v1
(by checking out v1
and running dbm-rollback
) and then checkout v3
and run dbm-update-sql
.
Is there a way to do this without rolling the development database back (or hacking away at the DATABASECHANGELOG
table)? Something like dbm-update-count-sql 2
which would create the SQL for the last two migrations regardless of whether they have already been run in development.
EDIT: cannot connect to the prod database from the development machine
Upvotes: 1
Views: 113
Reputation: 15783
If you are using updateSQL to generate the SQL, Liquibase makes no change to the database you are pointing it at, it just generates what it would execute on a normal update. So, the easiest option would be to just run updateSQL against your production database to get the script needed to update it.
If that does not work for you, if you are able to backup/restore the DATABASECHANGELOG table to another database (even an otherwise blank database) and run updateSQL against that, it will output the same SQL.
Finally, you can use "offline mode" to use a CSV file to act as the DATABASECHANGELOG table when running updateSQL. Running with an empty table will generate all update SQL, but if you include just the changes in the file that are in production, updateSQL will output just what is needed to update production.
Upvotes: 1
Reputation: 9016
If you can connect to the production database, you would just run liquibase with the updateSQL command.
Upvotes: 0