Forum: Ruby on Rails db:migrate vs. MySQL dump or good ol' DDL

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.
F591ddfdb8280c001a7f2d5a13fa0c2c?d=identicon&s=25 keith (Guest)
on 2007-05-15 15:16
(Received via mailing list)
Have people run into issues using db:migrate where you have gone back
to using MySQL dumps or DDL?  We are a first time Rails development
team and are trying to decide if we should use db:migrate in
production.  What are people's opinion's and experience with using
db:migrate in production environments?
F5d61a3c93217e393cfdf7bf5c7ac628?d=identicon&s=25 Michael D. Ivey (Guest)
on 2007-05-15 15:22
(Received via mailing list)
> Have people run into issues using db:migrate where you have gone back
> to using MySQL dumps or DDL?  We are a first time Rails development
> team and are trying to decide if we should use db:migrate in
> production.  What are people's opinion's and experience with using
> db:migrate in production environments?

Absolutely use migrations from day one.  I use the mysql console for
1 thing: creating the database.  Everything after that is done via
migrations.

I will periodically dump production and load it into development, so
I'm developing on a semi-current set of data, but I never ever ever
touch the production database directly.

Seriously.

Use migrations.

They are a Good Thing and will make your life much easier in the long
run.
Bc6c0fd7296921fb7eae416f7c9e86a1?d=identicon&s=25 David Richards (Guest)
on 2007-05-15 16:40
(Received via mailing list)
I use MySQL dumps for backups, and I'd never leave migrations.  It was
a bit of a learning curve to get the team used to the idea, and I
seemed to be always going back to the API to get the few options stuck
in my thick head, but now that I've made the switch, I'll never go
back.

If it were just an alternative way to load data definitions, that
would be one thing.  But it's also:

1) easier to see the evolution of the data structure without checking
out different versions of a single file
2) a whole lot easier to see-saw when debugging model issues (I just
rake db:migrate VERSION=12; rake db:migrate whenever I've got a
problem with the data/models in version 13, say.)
3) quicker to make database changes
4) easier to manage differences between databases (I use PostgreSQL,
MySQL, and SQLite for different projects, and the data requirements
between these are a lot simpler to manage in migrations than dumps or
DDLs.)

I've heard that all those migrations get unwieldy after a while.  I
can see their point.  I've dealt with projects with 50 and 60
migrations.  But, that's easy to fix.  Just take a current db/
schema.rb file and convert it into a migration (create a class and up
and down methods).  Then, you can replace those 50 or 60 migrations
with one migration file.
This topic is locked and can not be replied to.