Forum: Ruby on Rails Managing Database Alter Scripts

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
42f25d242aa8d725758481bfd04f3278?d=identicon&s=25 Britt Selvitelle (lukewarmtapioca)
on 2006-02-21 19:18
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
5d15c6821f3c3054c04b85471824ba7c?d=identicon&s=25 Joshua Schairbaum (Guest)
on 2006-02-21 19:28
(Received via mailing list)
>
>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/Understand...
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-02-21 19:28
(Received via mailing list)
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 Mornini
This topic is locked and can not be replied to.