CODEWITHSUNDEEP
liquibaseflyway
Adi Baron
Adi Baron

Reputation: 576

Can Liquibase or Flyway handle multi non-linear versioning scenario?

Here is a tough one.

  1. v1.1 has a table with index i.
  2. v2.1 contains this table and index as well.

A bug was discovered and in v1.1.0.1 we changes the code and as a result, decided to drop the index.
We created a corresponding patch for v2.1, v2.1.0.6.

The customer applied patch v1.1.0.1 and a few weeks later upgraded to v2.1 (without patch 6)

As v2.1 code base performs better with the index we have a "broken" application.

Can Liquibase or Flyway handle this scenario?

Upvotes: 2

Views: 1044

Answers (3)

Roman
Roman

Reputation: 23

The answer may be a bit late, but I will share my experience. We also came across the same problem in our project. We dealt with it in the next way:

Since releases in our project were not made often, we marked each changeset in liquibase particular context. The value was the exact version migration (like v6.2.1-v6.2.2). We passed value to liquibase though jndi properties, so customer was able to specify them. So during upgrade customer was responsible for setting right value for migration scope for each upgrade. Liquibase context can accept list of values. So in the end, context looked like this:

context=v5.1-5.2,v5.3-5.3.1,v5.3.1-5.4,v6.2.1-v6.2.2

Upvotes: 0

Nathan Voxland
Nathan Voxland

Reputation: 15773

Liquibase will handle the drop index change across branches fine, but since you are going from a version that contains code (a drop index change) to one that does not expect that you are going to end up with your broken app state.

With liquibase, changes are completely independent of each other and independent of any versioning. You can think of the liquibase changelog as an ordered list of changes to make that each have a unique identifier. When you do an update, liquibase checks each change in turn to see if it has been ran and runs it if it has not.

Any "versioning" is purely within your codebase and branching scheme, liquibase does not care.

Imagine you start out with your 1.1.0 release that looks like:

  • change a
  • change b
  • change c

when you deploy 1.1.0, the customer database will know changes a,b, and c were ran.

You have v2.1 with new changesets to the end of your changelog file, so it looks like:

  • change a
  • change b
  • change c
  • change x
  • change y
  • change z

and all 2.1 customers database know that a,b,c,x,y,z are applied.

When you create 1.1.0.1 with changeset d that drops your index, you end up with this changelog in the 1.1.0.1 branch:

  • change a
  • change b
  • change c
  • change d

But when you upgrade your 1.1.0.1 customers to 2.1, liquibase just compares the defined changesets of (a,b,c,x,y,z) against the known changesets of (a,b,c,d) and runs x,y,z. It doesn't care that there is an already ran changeset of d, it does nothing about that.

The liquibase diff support can be used as a bit of a sanity check and would be able to report that there is a missing index compared to some "correct" database, but that is not something you would normally do in a production deployment scenario.

Upvotes: 2

Jens
Jens

Reputation: 6383

I guess these kind of problems are more organizational and not tool-specific. If you support multiple Version (A branch 1.0 and a newer one 2.0) and provide patches for both (which is totally legitimate approach - don't get me wrong here) you will probably have to provide upgrade notes for all these versions and maybe a matrix that shows from which version to which you can go (and what you can't do).

I just happened to upgrade an older version of Atlassian's Jira Bugtracker and had to find out that they do provide upgrade notes for all versions.

That would have meant to go from one version to the next to finally arrive at the latest version (I was on version 4.x and wanted to go to the latest 5.x) and obey all upgrade notes in between. (Btw, I skipped all this and set it up as a complete fresh installation to avoid this.)

Just to give you an impression, here is a page that shows all these upgrade notes: https://confluence.atlassian.com/display/JIRA/Important+Version-Specific+Upgrade+Notes

So I guess you could provide a small script that recreates the index if somebody wants to go from version 1.1.0.1 to 2.1 and state in upgrade notes that it needs to be applied.

Since you asked if liquibase (or flyway) can support this, maybe it is helpful to mention that liquibase (I only know liquibase) has a something called preConditions. Which means you can run a changeset (resp. an sql) based on the fact that an (e.g.) index exists <indexExists>.

That could help to re-create the index if it is missing.

But since version 2.1 has already been released (before knowing that the index might be dropped in a future bugfix) there is no chance to add this feature to the upgrade procedure of version 2.1.

Upvotes: 3

Related Questions