Migrations - use them or not?

Hello,

As a rails newbie, i have stumbled upon some tutorials promoting
migratons. I have thought, wow, cool and started using them right away.
However, now that i am reading the RoR list on a daily basis, i have
seen also mails ranging from ‘migrations are not always the best’ to
‘migrations are evil’ and even ‘i would not use migrations even if…’

So i would be interested in your oppinion - what are the
downsides/possible problems/side effects (the pros are quite
straightforward, so i am not asking for those) of using migrations?

Thx,
Peter

The only problems I’ve ever had are:

  1. PostgreSQL support is sometimes not 100%. This is in 1.0 of the
    framework - can’t remember the exact issue, but it was something to do
    with the :null => false thing not being supported properly. In any
    case it just meant that I write my non-trivial alter table statments
    manually. This might be fixed now - I haven’t checked.
  2. Make sure you test going both up and down in migrations before you
    deploy, to make sure that the dropping of stuff works as you expected!

That being said, the ability to do changes on the fly without having
to muck about with manual change scripts is an awesome addition to the
framework.

Cheers,
Dan

Dan S. wrote:

That being said, the ability to do changes on the fly without having
to muck about with manual change scripts is an awesome addition to the
framework.
Well, i did not have exactly this on my mind (nevertheless thx for the
points, i am thinking about switching to postgre), since these can be
corrected manually - but there were some issues with database integrity
(FK contraints are not enforced or something like this) which can cause
serious problems (or at least the writer of the mail claimed - i could
not find the thread).

On Friday 28 April 2006 08:05, Peter S. wrote:

Well, i did not have exactly this on my mind (nevertheless thx for the
points, i am thinking about switching to postgre), since these can be
corrected manually - but there were some issues with database integrity
(FK contraints are not enforced or something like this) which can cause
serious problems (or at least the writer of the mail claimed - i could
not find the thread).

Peter

All the stuff I’ve done with Rails was against Postgres and I haven’t
seen any
problems so far. I had to declare my foreign keys in SQL but the syntax
is
pretty simple. There is a plugin to make it easier at
http://wiki.rubyonrails.org/rails/pages/Foreign+Key+Schema+Dumper+Plugin
but
I haven’t used it myself.

I would definitely go with migrations. At my company, I spent two
solid
months designing a system that lets us upgrade any version of our main
app to
any more recent version. With migrations that is handled for you. You
can
work away without any fear that you will miss something when you go live
with
your changes.

Another thing it enables you to do relatively easily is “continuous
integration”. This is where you have your computer regularly get your
latest
changes and check they deploy to an existing version of the app. This
isn’t
important for small projects, but in a big team it makes you much more
agile - you know within (say) an hour that someone has broke something
and
you can work on fixing it.

So basically I say yes to migrations because they make life easier in
the
simple case and prepare you to scale up your work later (same applies to
Postgres too!).

Ashley

Ashley, Dan,

Thx for your replies. It (hopefully) seems that the original author was
just FUD-ing around and there is no catch behind migrations (or? :wink:

Have a nice day,
Peter

On 4/28/06, Peter S. [email protected] wrote:

Well, i did not have exactly this on my mind (nevertheless thx for the
points, i am thinking about switching to postgre), since these can be
corrected manually - but there were some issues with database integrity
(FK contraints are not enforced or something like this) which can cause
serious problems (or at least the writer of the mail claimed - i could
not find the thread).

Well, I don’t know about that… I mean for me I always write FKs
into migrations in an execute block because I am quite picky about
that sort of stuff. In the end, all a migration is is a way to deploy
changes to the DB - it’s just executing a chunk of ALTER TABLE or
whatever, so as long as you can verify that it’s doing what you expect
and putting the right FKs in, then it’s up to the DB to make sure that
it happens.

Might the original author have been having troubles with a MyISAM
MySQL table? Perhaps the lack of transactions caused some problems?

Anyway, I use migrations regularly on my sites and although I do test
them with some vigour before I deploy them, I’ve yet to have a problem
apart from those I mentioned.

My 2c I guess.
Cheers,
Dan