deploy:cold and migrations

[ak]

Is there any way to have "cap deploy:cold" run the schema.rb file
instead of trying to migrate the empty database?

The schema.rb file is considered the 'authoritative' definition of the
db schema, so it makes sense to use this file to do initial database
setup instead of migrating from 0. In fact, in Rails 2 the schema.rb
file contains this statement:

# Note that this schema.rb definition is the authoritative source for
your database schema. If you need
# to create the application database on another system, you should be
using db:schema:load, not running
# all the migrations from scratch. The latter is a flawed and
unsustainable approach (the more migrations
# you'll amass, the slower it'll run and the greater likelihood for
issues).

The project I am working on has made me a firm believer that "the more
migrations you'll amass, . . . the greater likelihood for issues".
Old migrations are fragile if you make frequent model changes, and the
likelihood that a deploy:cold using migrations will work when
deploying to a new environment is slim to none.

[David Masover]

It seems like it'd be pretty easy to do, though you might have to override the deploy:cold task.

However, I think the reason for the current behavior is that loading the schema nukes whatever data was there. Using migrations is a sane default, in that it preserves data. The only way I can think to improve it would be to detect when none of the tables exist, and run db:schema:load in that instance -- and migrate if any tables exist.

[ak]

My understanding is that running deploy:cold is typically a one-time
setup operation, so there would be no data to nuke. If I'm wrong it
wouldn't be the first time.

Perhaps I'm missing something obvious, is it common practice to add
data to your application via migrations (something that would be
skipped by simply running the schema.rb file)? Maybe there are other
reasons to prefer migration from zero to loading the schema.rb file
directly during the initial setup of your app?

I will look into patching the deploy:cold behavior for my own project,
I guess my situation is somewhat abnormal. I know that if I don't fix
it the admin team will have my head.

Cheers,
Andrew Kappen

On May 23, 3:45 pm, "David Masover" <d...@3mix.com> wrote:
> It seems like it'd be pretty easy to do, though you might have to override
> the deploy:cold task.
>
> However, I think the reason for the current behavior is that loading the
> schema nukes whatever data was there. Using migrations is a sane default, in
> that it preserves data. The only way I can think to improve it would be to
> detect when none of the tables exist, and run db:schema:load in that
> instance -- and migrate if any tables exist.
>

[David Masover]

On Sun, May 25, 2008 at 9:17 AM, ak <aka...@gmail.com> wrote:

My understanding is that running deploy:cold is typically a one-time
setup operation, so there would be no data to nuke.

This is true.

Perhaps I'm missing something obvious, is it common practice to add
data to your application via migrations (something that would be
skipped by simply running the schema.rb file)?  Maybe there are other
reasons to prefer migration from zero to loading the schema.rb file
directly during the initial setup of your app?

Not really. Only one: If, for some reason, there is data there -- you ran deploy:cold accidentally, or you somehow got pointed at a different (critical) database, or whatever -- db:schema:load will happily blow it all away, while db:migrate will at least complain, and might even do the right thing.

So my guess is, it's done this way as a bit of a safety net.

I think db:schema:load should fail, instead of nuking what's there, if you run it on an existing database. There should be a separate rake task to run if there is data there which you actually want to nuke -- something like db:schema:drop_tables, or just db:nuke. But this would have to be patched in Rails first -- it's not Capistrano's domain.

I will look into patching the deploy:cold behavior for my own project,
I guess my situation is somewhat abnormal.

Probably not. I actually often do some of these steps manually, rather than trust deploy:cold, but I won't be able to keep that up forever.