# Now that I have migrations working (I think I do anyway) **URL:** \ **Category:** Rails\ **Created:** [February 13, 2006, 11:16pm UTC](https://www.ruby-forum.com/t/now-that-i-have-migrations-working-i-think-i-do-anyway/53713 "2006-02-13T23:16:56Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![craigrails](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c2a13f/32.png) [@craigrails](https://www.ruby-forum.com/u/craigrails)\ **Post date:** [February 13, 2006, 11:16pm UTC](https://www.ruby-forum.com/t/now-that-i-have-migrations-working-i-think-i-do-anyway/53713/1 "2006-02-13T23:16:56Z")
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 ---
**Author:** ![craigrails](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c2a13f/32.png) [@craigrails](https://www.ruby-forum.com/u/craigrails)\ **Post date:** [February 13, 2006, 11:31pm UTC](https://www.ruby-forum.com/t/now-that-i-have-migrations-working-i-think-i-do-anyway/53713/2 "2006-02-13T23:31:15Z")
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. ---
**Author:** ![craigrails](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c2a13f/32.png) [@craigrails](https://www.ruby-forum.com/u/craigrails)\ **Post date:** [February 13, 2006, 11:33pm UTC](https://www.ruby-forum.com/t/now-that-i-have-migrations-working-i-think-i-do-anyway/53713/3 "2006-02-13T23:33:36Z")
Craig W. 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. ---
**Author:** ![craigrails](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c2a13f/32.png) [@craigrails](https://www.ruby-forum.com/u/craigrails)\ **Post date:** [February 14, 2006, 12:43am UTC](https://www.ruby-forum.com/t/now-that-i-have-migrations-working-i-think-i-do-anyway/53713/4 "2006-02-14T00:43:32Z")
> * * * > > 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. ---
**Author:** ![craigrails](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c2a13f/32.png) [@craigrails](https://www.ruby-forum.com/u/craigrails)\ **Post date:** [February 14, 2006, 12:14am UTC](https://www.ruby-forum.com/t/now-that-i-have-migrations-working-i-think-i-do-anyway/53713/5 "2006-02-14T00:14:11Z")
On Mon, 2006-02-13 at 23:33 +0100, Jake J. wrote: > > 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 ---
**Author:** ![craigrails](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/c2a13f/32.png) [@craigrails](https://www.ruby-forum.com/u/craigrails)\ **Post date:** [February 14, 2006, 12:48am UTC](https://www.ruby-forum.com/t/now-that-i-have-migrations-working-i-think-i-do-anyway/53713/6 "2006-02-14T00:48:25Z")
On Feb 13, 2006, at 2:16 PM, Craig W. 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