[konha]

> How are teams of size >2 handling this?

Directory with .sql files starting with a number. Each file contains a set of changes to the db. The db has a table with the number that was applied last. To migrate your db you check if you have a file with a number that is higher than the one in the db. Then you apply that file to your db. That’s it.

Sounds like you are working in a way that is not intended by your tool / framework.

[foobarbaz33]

I do something similar.

We use a minified version of the production DB (baseline). People create numbered sql scripts. A helper script will restore the baseline DB on their local laptop, then apply the new sql files against it.

You develop a deployment script explicitly rather than have it generated. Automatic diff-based generation is full of holes. Making a deployment script directly works flawlessly for all all cases: renames, external data imports, flat files, etc.

Feature branches? no problem.

    git fetch
    git rebase origin/master. 

If someone adds a new script you just bump your script number and continue. Scripts are often order-independent, so even if you both make claim to 04_foo.sql it may not matter, and if it does you just bump your script to 05_foo.sql.

I've been using plain old sql scripts for many years with exactly 0 deployment issues. The fact everyone is constantly testing/validating a "deployment" on their local box is a huge win.

With a minified DB the full restore and script deployment can be done in under 10 seconds usually. With big data imports it may take longer, but those scripts can simply be renamed from 80_import.sql to 80_import.sql.SKIP for a faster iteration.

[ozozozd]

Assume you and your teammate made db changes and generated migrations in your respective topic branches. Both migrations refer to the latest revision, as it should be.

How do they merge? How does the migration tool know which migration to apply first?

Edit: You are right about us possibly not using the tools in the intended manner. But having to check the latest migration and check that with my local db seems a little bit error-prone and cumbersome, no?

[konha]

> How do they merge?

Manually. When you merge your code back into a common branch you look at the existing migrations and the new migrations and make sure the numbers make sense (after the merge). You can avoid stepping on each other’s toes by using a timestamp for the number in your filename. You still have to make sure (when you merge) the order makes sense.

> How does the migration tool know which migration to apply first?

Migrations are ordered by the (ascending) number in the filename. (Or some other scheme, but this is common)

> But having to check the latest migration and check that with my local db seems a little bit error-prone and cumbersome, no?

The number in the database should never be higher than the highest numbered file in source control. So you can increment without looking.

[ponyous]

We use timestamps in file names. Before you merge you have to catch up your branch (or it gets automatically updated). CI runs the migrations, so if something doesn't work you will know it.

[isbvhodnvemrwvn]

Pretty much what Flyway does.