Rails - Feb 2006 - Managing Database Alter Scripts

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

-- 
Posted via http://www.ruby-forum.com/.

>
>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



-- 
Posted with http://DevLists.com.  Sign up and save your time!

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

On Feb 21, 2006, at 10:18 AM, Britt Selvitelle wrote:
> 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.