1

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?

Combo
  • 855
  • 2
  • 11
  • 22

3 Answers3

2

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.

Axel Fontaine
  • 34,542
  • 16
  • 106
  • 137
  • >what the next available version number is What if 5 people are going to do migrations and they do not know who will be first? – Combo Mar 27 '18 at 07:48
  • Read it again. It's in my answer. – Axel Fontaine Mar 27 '18 at 09:37
  • 1
    dev1 can complete before dev2, but migration of dev1 depends of migration of dev2, so the order will be wrong – Combo Mar 27 '18 at 09:40
  • If that's the case then dev1 and dev2 must really talk to each other as there will most likely be even more things to watch out for than simply a version number in a filename. – Axel Fontaine Mar 27 '18 at 10:19
0

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.

M. Schreiber
  • 96
  • 5
0

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
Igor Rocha
  • 25
  • 5