Rails - Feb 2006 - now that I have migrations working (I think I do anyway)

Do I now define database changes directly in

db/migration/0001_add_a_new_table

file ? 

Obviously the point is not to make the changes directly in postgresql db
anymore right?

Thanks

Craig

Yep - at least that''s what I''m doing and it''s as
straightforward as
shown in the video on the Rails site.

It''s SOOO good to be able to track database changes along with source
code changes - relieves a problem that''s troubled mankind throughout
the ages...  Plus you can e.g. insert reference data through your
migration file, which chops off another big problem area.

Regards

Dave M.

On 14/02/06, Craig White <craigwhite@azapple.com>
wrote:
> Do I now define database changes directly in
>
> db/migration/0001_add_a_new_table
>
> file ?
>
> Obviously the point is not to make the changes directly in postgresql db
> anymore right?
>
> Thanks
>
> Craig
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

Craig White wrote:
> Do I now define database changes directly in
> 
> db/migration/0001_add_a_new_table
> 
> file ?
> 
> Obviously the point is not to make the changes directly in postgresql db
> anymore right?
> 
> Thanks
> 
> Craig
Essentially -- just do

ruby script/generate migration AddANewTable

and it will create the file for you and automatically increase the 
migration version number on the file.

Then do "rake RAILS_ENV=development migrate VERSION=4" (or whatever)
do
perform the migration on the database you''re working with.  It will 
check the database "schema_info" table to see which version
you''re
currently at and run the migrations accordingly.

It apparently doesn''t do the migrations in a transaction because
I''ve
had it leave the migration in when something fails...  But at least I 
can do this while I''m debugging and manually delete the changes.

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

On Mon, 2006-02-13 at 23:33 +0100, Jake Janovetz wrote:
> Craig White wrote:
> > Do I now define database changes directly in
> > 
> > db/migration/0001_add_a_new_table
> > 
> > file ?
> > 
> > Obviously the point is not to make the changes directly in postgresql
db
> > anymore right?
> > 
> > Thanks
> > 
> > Craig
> 
> Essentially -- just do
> 
> ruby script/generate migration AddANewTable
----
OK but I already did the dump_schema thing and put the contents into
db/migration/0001_add_a_new_table so I don''t actually need to run
generate migration again do I ?  It''s already a schema_info table with
a
value of 0 in my development_db
----
> 
> and it will create the file for you and automatically increase the 
> migration version number on the file.
> 
> Then do "rake RAILS_ENV=development migrate VERSION=4" (or
whatever) do
> perform the migration on the database you''re working with.  It
will
> check the database "schema_info" table to see which version
you''re
> currently at and run the migrations accordingly.
----
my thinking is that I now just simply alter this file...the file
db/migration/0001_add_a_new_table with new columns in the proper table
and then I do the rake thing and it puts these columns into the db
indicated by my RAILS_ENV= ? 

Am I headed in the right direction?
----
> 
> It apparently doesn''t do the migrations in a transaction because
I''ve
> had it leave the migration in when something fails...  But at least I 
> can do this while I''m debugging and manually delete the changes.
----
Trying to inspire confidence eh?

Craig

> ----
> my thinking is that I now just simply alter this file...the file
> db/migration/0001_add_a_new_table with new columns in the proper table
> and then I do the rake thing and it puts these columns into the db
> indicated by my RAILS_ENV= ?
> 
"simply alter this file" - Ummm, no.  Generate a new migration for
each
set of
mods you''re making.  The idea is to capture the change history.

Besides, if the migration number (the 001 on the front) matches the
schema_version in the database, the migration won''t be run.

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

On Feb 13, 2006, at 2:16 PM, Craig White wrote:
> Do I now define database changes directly in
>
> db/migration/0001_add_a_new_table
>
> file ?
>
> Obviously the point is not to make the changes directly in  
> postgresql db
> anymore right?
Yes, generally speaking you''ll have 0 or 1 migration file per release.

With respect to that, I see very little need to actually use migrations
in the track changes over time sense until you''re in production. During
development I just modify the first few (creation and static loaders) to
keep things as simple as possible.

If you do migrations during early development, it''s likely
you''ll end
up referencing models that don''t exist anymore and such.

Of course, this can happen after you''ve gone into production as well,
but things should be a bit more stable after that.

-- 
-- Tom Monrnini