CODEWITHSUNDEEP
liquibaseflyway
Combo
Combo

Reputation: 1005

Flyway migrations order

We use Liquibase, and now in new project we must use Flyway. In liquibase migrations order is in xml file, so you specify what migration are first and what are second, it do not depends on names.

So, when some developer add new migration, if before that someone else pushed a new migration he would get a conflict in Git, and it must fix ordering.

How this is done in Flyway? How to control order if migrations are added in parallel?

Upvotes: 1

Views: 7775

Answers (3)

Igor Rocha
Igor Rocha

Reputation: 37

I've created a simple bash script to add a timestamp prefix when creating migrations, much like Ruby on Rails does. I'm not fluent in bash, so it's pretty simple, but it gets the job done.

The versioned migration name will look like: V20191010172609554__migration_description.sql

#!/bin/bash

set -e

help="Create a blank migration for flyway.\n\nUsage:\n-d\tDescription of the migration (will be set as the filename). Surround description with \"\".\n-t\tThe type of the migration. R for reusable, V for versioned."

while getopts ":t:d:h:" opt; do # get named arguments t, d, and h
  case $opt in
    t) type="$OPTARG"
    ;;
    d) desc="$OPTARG"
    ;;
    h) echo -e $help
    ;;
    \?) echo -e "Invalid option -$OPTARG \t Run with -help to see valid options." >&2
    ;;
  esac
done

if [[ -n $type && -n $desc ]]; then

  temp=$(echo "$desc" | sed "s/ /_/g") # replace spaces by underscores
  desc=$(echo "$temp" | sed "s/__/_/g") # replace possible duplicated underscores

  if [ "$type" == "V" ]; then
    timestamp="$(date +"%Y%m%d%H%M%S%3N")"
    migration_name=$type$timestamp"__"$desc.sql
  else
    migration_name=$type"__"$desc.sql
  fi
  touch "../migrations/"$migration_name

  echo "Created blank migration:"
  ls ../migrations/ | grep $migration_name 
  echo "in the migrations folder"
fi

Upvotes: 0

M. Schreiber
M. Schreiber

Reputation: 106

You should agree on a naming convention, which is easy to resolve when getting a conflict.

For example:

V0_11_005__ddl_create_module_table.sql

Where V0_11 is e.g. your current version number. Following by a 3 digit number default incremented by 5 (for example)

So imagine Version 11 is your fresh version where the devs start to work on:

  • Developer 1 is creating V0_11_005__ddl_create_foo.sql
  • Developer 2 is creating V0_11_005__ddl_create_bar.sql
  • Developer 1 pushes changes and they get merged
  • Developer 3 (starting from merged-branch) creates V0_11_010_ddl_create_stuff.sql

This will fail when Developer 2 trys to merge his changes, since 2 files have the same Version Number. Dev 2 simply renames it to V0_11_006__ddl_create_bar.sql.

So order of Dev1, Dev2, Dev3 scripts will be fine.

Upvotes: 0

Axel Fontaine
Axel Fontaine

Reputation: 35169

Start by reading https://flywaydb.org/documentation/migrations

For unique version numbers you can use something like a wiki page or the corner of a whiteboard to indicate what the next available version number is. A developer can then grab it and update it for the next one who needs one. Alternatively you can also use a reverse timestamp as a version.

Upvotes: 2

Related Questions