Want to replace old migration script file with new ones

Liquibase Development
1

Hi team,

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 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.

2

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.

1 Like
3

I have another suggestion, like what if I simply replace the old with new distributed changelogs & give precondition check to the run the new ones, if table not exists, would it be fine?

Since the tables are there, this wont run. so no table exist error.
Older abc-init.xml is removed, so if we deploy into a fresh db, it will be like running the new changesets only.

4

Yes, using preconditions on your changeset is another good option.

1 Like
5

Thanks @daryldoak . 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.

I would also like to know, whether there is any limitation/impact in marking this transaction as MARK_RAN instead of EXECUTED in databasechangelog file in future?

6

MARK_RAN is treated the same as EXECUTED in the databasechangelog table.

The only thing you have to be careful with about preconditions is if the existing table structure in the database is different than the table structure in the changelogs. In that case you are “ignoring” an actual change that is needed.

1 Like
7

Thanks a lot @daryldoak .

1 Like
8

I have a similar problem.

We currently have a whole bunch of scripts that have been running fine for a few years.

A forthcoming upgrade to the server means that the syntax in that script is no longer valid on new deployments; if we change the syntax to align with the new version of the database server the scripts will run fine on new deployments, but break existing deployments as the checksum will have changed.

Are we going to have to manually change the checksum in existing deployments, or is there a better way around this?

Thanks.

9

Hi @gdt do you still need to keep the older version of scripts?

if not, I think, we can replace it with those new scripts and add a precondition for new changesets. (like changeSetExecuted )