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