Adding the after hook in your deploy.rb may be too late because of callback
execution ordering. This could cause your migrations to attempt to run before
you've ensured the database.yml is correct, which is why I suggested using a
before deploy:symlink in my previous post. This ensures any hooks placed on
update_code are done before migrations try to run.
On Jan 3, 2012, at 8:42 AM, Lee Hambley <lee.hamb...@gmail.com> wrote:
> Matt,
>
> The original (and standing) reason is that most "toy" projects can get away
> with running migrations on every deploy, but for larger organisations, and
> more complicated projects which use Capistrano we expect professional
> developers to know what they are doing, and not run migrations (which can
> quite easily take a system offline) at deploy time unless they ask for it.
>
> Possibly destructive changes to a database which might cause downtime should
> always be opt-in, not opt out.
>
> Naturally if someone is using Capistrano with Git/Subversion/other - then no
> changes to the code are destructive, resources can be rebuilt, etc; but the
> database holds such a massive potential for downtime that it's not worth
> risking it.
>
> At this point in Capistrano's history (some 5 years after it was first
> gaining wide acceptance) - I think it would be foolish and unwise to change
> the default, as at least I rely on the behaviour.
>
> It's certainly even a difference between PostgreSQL and MySQL, the two behave
> very differently regarding large table changes, there is no "safe" default.
>
> I would suggest a compromise that a variable be made available that would
> cause migrations to run after you `deploy`, if that would help ease the
> transition for everyone.
>
> It's worth pointing out that the API is flexible enough that you can easily
> hook migrations to `after('deploy:update_code')`, which is effectively what
> `deploy:migrations` does.
>
> Thanks for brining this up Matt, I'd look forward to a patch, or further
> discussion if you are so inclined!
>
> - Lee
> On Tuesday, January 3, 2012 at 5:36 PM, Matt wrote:
>
>> Hi,
>>
>> Just curious - why is the default for `cap deploy` to *not* run migrations?
>>
>> I accept that there may be some circumstances in which you'd want to skip
>> migrations on a deploy (long-running migrations you'll run later, I guess?).
>> But, in my years of deploying many many different rails apps, I can only
>> think of a handful of times I've wanted to deploy but not run migrations.
>> And even then, it was probably best done as a separate rake task.
>>
>> Indeed, whenever I start a new rails project I use RailsMachine's excellent
>> "moonshine" which runs migrations automagically. I don't even know if
>> there's a way to disable migration running on moonshine?
>>
>> In any rate, it seems like it would best be done the other way around - `cap
>> deploy` does migrations, too, and `cap deploy:nomigrations` does what it
>> says. Is there something I'm missing?
>>
>> Thanks,
>>
>> --
>> Matt
>> --
>> * You received this message because you are subscribed to the Google Groups
>> "Capistrano" group.
>> * To post to this group, send email to capistrano@googlegroups.com
>> * To unsubscribe from this group, send email to
>> capistrano+unsubscr...@googlegroups.com For more options, visit this group
>> at http://groups.google.com/group/capistrano?hl=en
>
> --
> * You received this message because you are subscribed to the Google Groups
> "Capistrano" group.
> * To post to this group, send email to capistrano@googlegroups.com
> * To unsubscribe from this group, send email to
> capistrano+unsubscr...@googlegroups.com For more options, visit this group at
> http://groups.google.com/group/capistrano?hl=en
--
* You received this message because you are subscribed to the Google Groups
"Capistrano" group.
* To post to this group, send email to capistrano@googlegroups.com
* To unsubscribe from this group, send email to
capistrano+unsubscr...@googlegroups.com For more options, visit this group at
http://groups.google.com/group/capistrano?hl=en
