Managing Database Alter Scripts

Rails
1

I just posed this question to #subversion, with no reply. Any thoughts
here?

I’m trying to decide how to manage database changes w/ subversion.

I’ve got a large number of production checkouts of a branch (actually,
multiple branches). Of course I have a base script to create the schema,
and this is updated of course when new fields are added to the system.

When a new field is added for a bug fix in a release branch, I need to
run alter scripts across all existing installs of the database.

Does anyone know known practices for managing these in the repository?
Rake migrate scripts? Etc? I’m trying to come up with a good schema to
keep track of which have been run on all live production servers, and
which still need to be run for a given revision in the repository.

Any thoughts?
Britt

2

Any thoughts?

I would certainly think that some sort of combination of AR migrations
and SwitchTower would fit the bill nicely. The migrations ‘schema_info’
table would let you know what version you were currently at and
SwitchTower would allow you to change them all at once. I use
Migrations constantly, SwitchTower I haven’t the need yet.

Migrations information can be found here:

http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations

3

This is a great question and something I’ve been putting some thought
into…

Seems to me we need to tie DB version to application release number,
perhaps via SVN tagging.

Additionally, I think that migrations scripts need branch numbering
and the ability to traverse a release tree, via the branch numbering.

i.e. 2.1.4 of the application should run migration scripts: (example)

001
002
002.1
002.1.1
002.1.2
002.1.3
002.1.4

So, I guess I’m proposing a one migration per release methodology, to
make this easily trackable.

–
– Tom M.