Need a config for using scripts as the version

[developingchris]

I have a project, that I would like to use roundhouse on. But it's in subversion, and there are 30-40 databases being updated by the same repository.

The scripts are shared and the structure is shared, but the dll versions are disparate of their various consuming web front ends.

So an xml file per database as to what the version is, would be cumbersome and kind of strange when branching.

My proposition is an alternate versioning scheme where the version you are upgrading to is the highest up script in the directory's serial number. For example if the last script in up is 0181_made_user_change.sql. Then you would be going from version whatever to version 181. So the scripts themselves are the version if you choose a config option.
This makes versioning down much more intuitive. Since the scripts themselves can tell you where you are going to.

I'm working up a pull request for this, but wanted to get thoughts on whether or not it would be appropriate to put in to the main release.

[ferventcoder]

Neither XML nor pointing to a DLL to grab the version will work for you in this case? I would be accepting of something that looked at the highest number of what is in the up folder. The only thing I will caution you on is real world usage, 2 people may name the script with the same number. That could potentially cause issues with the idea of a global version. Also keep in mind that there is nothing that keeps someone from running a lower numbered script later...this would look kind of strange to see the version number go down. Once again, not pointing to theories, real world use and what I have seen.

[developingchris]

I think its worth a look and a try.
I know that the dll versioning has a significant use case.

However, in the case of a multi tennant solution, where the logic and the schema move at different paces, and or you have 3-4 different dlls on the same database. It is very strange to see something upgrading the database from version 1 to version 2, except the scripts are identical and you are really still at version 1 of the schema.

Xml files solve this, except now you need to bake in a step to bump the version file, or else you get even more strange behavior, moving from current version 1, to next version 1, and changes were applied. So you were at version 1, you ran the roundhouse, now you are at version 1, but a different version 1.

Script serial numbers are by no means perfect, but it does also aid significantly in downward progression as well. Most other frameworks have gone to much larger numbers, generated from a generator, that begin with a timestamp, reducing the likelihood of a collision. Although if you are on version 15 and add scrip 2, and then run and it goes from version 15 to version 15, it will still be quite confusing. I'm not sure there is a good answer.

I really like the project and want to use it a lot. If I can get this implemented shortly, I'll be able to put it into a few hundred CI builds with in a couple of weeks.

[developingchris]

I have added a pull request with an implementation of the script versioning that worked well on the first 3 databases I was playing with roundhouse on.

[ferventcoder]

up to your notes I just had a couple of points. When we versioned the database from multiple repositories, part of the version was the revision and we also passed in the repo path. That way there was no contention on what version it was on. So we were never on version 1 and version 1. We were always on version 1.0.23.323 (repo #1), version 1.0.12.1201 (repo #2). We kept our scripts in source control so the tight coupling to revision meant we were never versioning in an arbitrary sense like you described above.

With DLLs, we also versioned our DLLs with the revision as part of them as well.

These things were/are required by SOx, a huge part of why RH exists in the first place.

[ferventcoder]

It's funny you mention downward progression. I had actually been thinking that the only way to down a migrator like roundhouse was to provide a script in the down directory with the exact same name as the one in the up directory. Then you would move versions down by specifying the script you wanted to move "down" to. :D

[ferventcoder]

Forgot to mention we used uppercut, which creates a file during the build process called "_BuildInfo.xml" (the default file used by RH). So we never forget to bump a generated at build time file. ;)

The chucknorris framework is about tools that integrate together nicely, but each of which are not required to use the other. If that makes any sense. :D

[developingchris]

I looked into using uppercut, but my builds are already done, much more simply, and in a way that all of my colleagues have been able to understand. Although a fantastic running start the amount of Nant insider baseball going on to get simple modifications in, is too much. And it's xml and not really intuitive programming.

We have jenkins running albacore, and a relatively straight forward build and test build file in rake is 10 lines. Using simple conventions.
A multi headed solution, 3 service projects, 4 web front ends and 3 different unit test projects, including conditional deploy of any one of the 7, is still under 100 lines of albacore, most of that is the path differences and namespacing to get nice command line documentation with a rake -T.
So while they work well together, I think we'll kick our database and dolphin safe our builds.

[ferventcoder]

I agree with the uc / nant thing. uc v2 will be code-based. The thing most people miss there is that they don't have to write a line of nant to use uppercut. And extension points can be rake/albacore or powershell.

No biggie, just think of making your build do more for you in the way of generating information. :D

[ferventcoder]

Nice, rake for build and deploy. :D