Forum: Ruby on Rails now that I have migrations working (I think I do anyway)

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.
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-02-13 23:16
(Received via mailing list)
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
F3dc06f587d1ff4c7366b102bfda9204?d=identicon&s=25 David Mitchell (Guest)
on 2006-02-13 23:31
(Received via mailing list)
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.
Ff43001ac5fe9805aa6ca2e89d3b7b5d?d=identicon&s=25 Jake Janovetz (janovetz)
on 2006-02-13 23:33
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.
C1e5a9e9344b6d31b9df7303e6dc378a?d=identicon&s=25 Craig White (Guest)
on 2006-02-14 00:14
(Received via mailing list)
On Mon, 2006-02-13 at 23:33 +0100, Jake Janovetz 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
613957d83c5285e4dc4a10887e2bfe36?d=identicon&s=25 jaker (Guest)
on 2006-02-14 00:43
> ----
> 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.
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-02-14 00:48
(Received via mailing list)
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
This topic is locked and can not be replied to.