Comments on: Continuous Database Integration – video

By: lilikindsli

lilikindsli — Sun, 04 Oct 2009 23:48:31 +0000

JECt19 I want to say – thank you for this!

By: erichexter

erichexter — Fri, 18 Sep 2009 17:41:30 +0000

@zvolkov, It does have a small concept of a version. When it tracks the scripts that are applied to the database it logs the time but it also logs the batch of scripts that were applied as a batch. This number is essentially the total number of migration scripts that have been run against the system. So in the case of this video the version of this database was 11. This does not directly correlate back to the version of the application which the changes correspond to. We really heavly rely on the fact that the scripts in source control are the correct scripts to run with the code in source control. So yes this does make branching very easy since there are very few constraints around keeping scripts tied to say an assembly version number.

By: zvolkov

zvolkov — Fri, 18 Sep 2009 14:53:35 +0000

If I understand correctly what makes Tarantino unique comparing to other SQL-based tools is that it has no concept of “version”. Instead it runs all not-yet-applied scripts in alphabetical order. This is very powerful as it not only allows any file naming convention but also supports bunch of branching / merging scenarios.

By: Ben Scheirman

Ben Scheirman — Fri, 18 Sep 2009 13:14:28 +0000

@erichexter what we do for this is immediately gets the latest on that folder and checks-in an empty file.

So when I do a migration, I must download the others first, so the numbering stays right. it then checks in an empty file, so that others get the same benefit.

Migrations run without hiccup.. .and when I’m done with my change, I check it in and other migrations notice that they haven’t run it and they include it in the update.

In some cases it requires a:

migration run 12 (a few versions back)
migration run (to get back to current)

but that hardly happens.

By: erichexter

erichexter — Fri, 18 Sep 2009 02:44:34 +0000

@jason we normally do not have file merge conflicts as the file names are unique. If two different feature branches are each adding files to their branch then the first branch to merge back into the trunk gets to commit and the last branch to merge must renumber their files if they fail.

Right now the tarantino tool will allow duplicate file number prefixes but I would like to add a check in the tarantino tool that would fail if there were two duplicate file prefixes. This would force the developer who has not committed to update their files if there was a conflict.

By: Jason West

Jason West — Fri, 18 Sep 2009 02:16:23 +0000

Would be interesting to see how you do merges at varying levels of divergence and when there are merge conflicts.