Can Liquibase or Flyway handle multi non-linear versioning scenario? -
here tough one.
v1.1
has table index i.v2.1
contains table , index well.
a bug discovered , in v1.1.0.1
changes code , result, decided drop index.
created corresponding patch v2.1
, v2.1.0.6
.
the customer applied patch v1.1.0.1
, few weeks later upgraded v2.1
(without patch 6)
as v2.1
code base performs better index have "broken" application.
- i can't force customers apply latest patch.
- i can't force developers avoid such scenarios.
can liquibase or flyway handle scenario?
liquibase handle drop index change across branches fine, since going version contains code (a drop index change) 1 not expect going end broken app state.
with liquibase, changes independent of each other , independent of versioning. can think of liquibase changelog ordered list of changes make each have unique identifier. when update, liquibase checks each change in turn see if has been ran , runs if has not.
any "versioning" purely within codebase , branching scheme, liquibase not care.
imagine start out 1.1.0 release looks like:
- change a
- change b
- change c
when deploy 1.1.0, customer database know changes a,b, , c ran.
you have v2.1 new changesets end of changelog file, looks like:
- change a
- change b
- change c
- change x
- change y
- change z
and 2.1 customers database know a,b,c,x,y,z applied.
when create 1.1.0.1 changeset d drops index, end changelog in 1.1.0.1 branch:
- change a
- change b
- change c
- change d
but when upgrade 1.1.0.1 customers 2.1, liquibase compares defined changesets of (a,b,c,x,y,z) against known changesets of (a,b,c,d) , runs x,y,z. doesn't care there ran changeset of d, nothing that.
the liquibase diff support can used bit of sanity check , able report there missing index compared "correct" database, not in production deployment scenario.
Comments
Post a Comment