Forum: Ruby on Rails I still don't understand migrations

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.
42172acdf3c6046f84d644cb0b94642c?d=identicon&s=25 pergesu (Guest)
on 2005-11-12 12:49
(Received via mailing list)
I've never used migrations, and everyone on IRC calls me crazy because
of that.  Still have yet to get any real responses as to why I'm crazy
though...

I'm writing a new app now, but I don't know the whole db schema for
the entire app.  Go figure, that's just how it works.  I'll add a
bunch of tables, edit tables, etc as the app chugs along.  Figured
that migrations would be a good way of handling this, compared to
editing a schema file and having to drop and create the database every
time.  Migrations are also apparently good for updating production
DBs, where you obviously can't just drop them.

My question is how to get started then...ideally I'd do everything in
the migrations as opposed to having a SQL create script, because I
don't want to have to maintain it in two places.  Can I do everything
with migrations that I can with SQL, such as create serial columns and
custom sequences in PostgreSQL?  How about foreign key constraints?

I'm just unable to find the docs for migrations really, because I've
yet to find a lot of info on them.  Some stuff in the wiki, but
nothing that answers my questions.  They seem to be very popular, but
surely nobody's using them if they don't have the ability to handle
things that everyone uses in their databases (auto_incremement in
MySQL, etc).  Can anyone answer these questions, or point me to a
source for more info?

Thanks,
Pat
10d9ed7ab11115b081bb36f56a7a13bc?d=identicon&s=25 johnwilger (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On 11/10/05, Pat Maddox <pergesu@gmail.com> wrote:
> I'm writing a new app now, but I don't know the whole db schema for
> the entire app.  Go figure, that's just how it works.  I'll add a
> bunch of tables, edit tables, etc as the app chugs along.

Which, IMHO, is how you _should_ do it in most cases. YAGNI and all
that jazz. ;-)

> My question is how to get started then...ideally I'd do everything in
> the migrations as opposed to having a SQL create script, because I
> don't want to have to maintain it in two places.  Can I do everything
> with migrations that I can with SQL, such as create serial columns and
> custom sequences in PostgreSQL?  How about foreign key constraints?

AFAIK, you can do anything with migrations that you would do
otherwise. If what you want to do isn't implemented in the schema DSL,
you can always execute raw SQL using the #execute method within your
migration:

  class ExampleMigration
    def up
        execute "any sql you want"
    end
  end

> I'm just unable to find the docs for migrations really, because I've
> yet to find a lot of info on them.

Did you find
http://api.rubyonrails.com/classes/ActiveRecord/Mi... ?

Hope that helps. If you have more specific questions not covered by
the above, feel free to ask.

--
Regards,
John Wilger
http://johnwilger.com
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 francois.beausoleil (Guest)
on 2005-11-12 12:49
(Received via mailing list)
Hi !

2005/11/10, Pat Maddox <pergesu@gmail.com>:
> My question is how to get started then...ideally I'd do everything in
> the migrations as opposed to having a SQL create script, because I
> don't want to have to maintain it in two places.  Can I do everything
> with migrations that I can with SQL, such as create serial columns and
> custom sequences in PostgreSQL?  How about foreign key constraints?

You can use any methods in ActiveRecord::SchemaStatement [1] to update
your schema.  Note the #execute method - it allows you to execute
arbitrary SQL.

If you target PostgreSQL, and your production DB is also on PSQL, you
can use #execute to setup serial columns and custom sequences.

Hope that helps !
--
François Beausoleil
http://blog.teksol.info/

[1]
http://api.rubyonrails.com/classes/ActiveRecord/Co...
722a18819725c0f6275b556ced89a3f4?d=identicon&s=25 se (Guest)
on 2005-11-12 12:49
(Received via mailing list)
>
> If you target PostgreSQL, and your production DB is also on PSQL, you
> can use #execute to setup serial columns and custom sequences.
>
> Hope that helps !
> --
> François Beausoleil
> http://blog.teksol.info/
>
> [1] 
http://api.rubyonrails.com/classes/ActiveRecord/Co...

Still doesn't explain why he has to use migrations for it. I think in
Pat's
case, when you just execute arbitrary db specific statements it might
not
be as useful as with let's say Typo, where you target more than one
database and compromise on a feature set which works with all of them.
In
that case, all can use the same schema file.

Sascha Ebach
B84d42a3a5c343f8fc6ab7d7f47fd3f5?d=identicon&s=25 robby.lists (Guest)
on 2005-11-12 12:49
(Received via mailing list)
On Fri, 2005-11-11 at 08:38 +0100, Sascha Ebach wrote:
> >
> Still doesn't explain why he has to use migrations for it. I think in Pat's
> case, when you just execute arbitrary db specific statements it might not
> be as useful as with let's say Typo, where you target more than one
> database and compromise on a feature set which works with all of them. In
> that case, all can use the same schema file.
>
> Sascha Ebach

This could work a few ways. As a PostgreSQL user, I find myself adding a
few extra non-My$QL features at times. What Migrations provides is a
nice framework and methodology for handling incremental changes to my
schema. I'm currently using a combination of #create_table and #execute
methods to achieve my evolving database schema. (things change)

Having one huge schema file is nice to have for that initial import...
but as changes occur, tracking what changed... in what order is nice to
have a record of. So you can do this yourself through your own method of
managing changes... or use the ever-so-convenient Migrations to stick
these changes in. You don't *have* to use it... but I would highly
suggest that you do... or model your home-brewed process after it.

My 2 cents,

-Robby
2073c7e0e7d2311727b680a887a375be?d=identicon&s=25 leonleslie (Guest)
on 2005-11-12 12:50
(Received via mailing list)
How about foreign key constraints?



On 11/11/05, Robby Russell <robby.lists@planetargon.com> wrote:
> > > arbitrary SQL.
> >
> nice framework and methodology for handling incremental changes to my
> My 2 cents,
> *******************************************************/
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


--
First they laugh at you, then they ignore you, then they fight you.
Then you win.
-- Mahatma Karamchand Gandhi
A82ba1167f4d4a8d1de63820e576a87f?d=identicon&s=25 robby (Guest)
on 2005-11-12 12:50
(Received via mailing list)
On Fri, 2005-11-11 at 12:01 -0400, Leon Leslie wrote:
> How about foreign key constraints?

Just add a new migration for adding constraints:


# db/migrate/6_add_foreign_key.rb
class AddForeignKey < ActiveRecord::Migration
  def self.up
    execute "ALTER TABLE bees ADD CONSTRAINT beehive_id_fkey FOREIGN KEY
(beehive_id) REFERENCES beehives (id);"
  end

  def self.down
    execute "ALTER TABLE bees DROP CONSTRAINT beehive_id_fkey;"
  end
end

rake migrate VERSION=6
...adds fkey

rake migrate VERSION=5
...rolls back and removes fkey

It's useful for testing. :-)

Robby
This topic is locked and can not be replied to.