CODEWITHSUNDEEP
databasemigrationliquibasecorda
Benjamin
Benjamin

Reputation: 115

Want to replace old liquibase migration script file with new ones

I am using liquibase scripts with Cordapp. And previously the first version databaseChangeLog file was having all table creations in one single change set and in a later point of time we have split it into different databaseChangeLog having each changeset.

Now the problem is some production testing environments have the data in it with the older script, but we want to use the new scripts.

The change done is like →

Old: abc-master.xml contained abc-init.xml (usual way)|

Now: abc-master.xml contains abc-v1.xml and abc-v1.xml contains table-v1.xml files for each table creation

Solution we were thinking is like,

create new tables with slight name change → then copy the data from old tables here → then drop old tables. So then we can remove old tables and old scripts (i assume)

Still the DATABASECHANGELOG will probably have the old scripts data, would that be a problem? Or is there a far better way to do this?

Many thanks.

Upvotes: 0

Views: 1175

Answers (2)

Benjamin
Benjamin

Reputation: 115

we are planning to go with

<preConditions onFail="MARK_RAN">
       <not>
           <tableExists tableName="MY_NEW_TABLE"/>
       </not>
   </preConditions>

For all those table creation changeset in new distributed structure ones, so our assumptions are:

We can keep this new structure alone in code & remove the old INIT file. For environments having existing data, eventhough these new structure of changesets will be considered as new changeset to run, the preconditions will prevent it running. For fresh db deployments, it will work as expected, by creating all the required tables.

Upvotes: 0

Daryl Doak
Daryl Doak

Reputation: 244

I answered this also on the Liquibase forums, but I'll copy it here for other people.

The filename is part if the unique key on the databasechangelog table (ID/Author/Filename). So when you change the filename of a changeset that has already executed, that is now in-fact a new changeset according to Liquibase.

I normally recommend that my customers never manually update the databasechangelog table, but in this case I think it might be the best course of action for you. That way your new file structure is properly reflected in the databasechangelog table.

I would run an update-sql command on the new file structure, against one of your database where you have already executed the chagesets. This will show you what changesets are pending, and also the values for the filenames that you need to update.

Upvotes: 1

Related Questions