On Thu, 2011-07-28 at 05:23 -0400, Chris Lalancette wrote:
On 07/28/11 - 09:57:56AM, Mark McLoughlin wrote:
> On Wed, 2011-07-27 at 04:35 -0400, Chris Lalancette wrote:
> > diff --git a/src/db/migrate/20110124103216_create_delayed_jobs.rb
b/src/db/migrate/20110124103216_create_delayed_jobs.rb
> > deleted file mode 100644
> > index 943ff9b..0000000
> > --- a/src/db/migrate/20110124103216_create_delayed_jobs.rb
> > +++ /dev/null
> > @@ -1,21 +0,0 @@
> > -class CreateDelayedJobs < ActiveRecord::Migration
> > - def self.up
> > - create_table :delayed_jobs, :force => true do |table|
>
> Is this really the right thing to do? Why aren't we adding a new
> migration which removes the table?
Hey Mark,
The reason I removed this initially is because I was getting errors along
the lines of "delayed_job gem missing" when trying to run this migration.
Now,
I didn't investigate all that closely at the time, so it is possible that there
was something else causing that error and this was just a red herring.
I think that was because of src/config/initializers/delayed_job.rb not
the migration
I doesn't look like the migration uses delayed_job itself
However, that being said, I think Jay, Scott, Matt, and I came
to the
conclusion that deleting migrations is a safe thing to do. That is, if you are
upgrading from a version previous to this, the migration won't have any idea
about the delayed_jobs table, and will just ignore it. It will be an unused
table in the database, but it shouldn't harm anything. And since we don't have
any "real" users yet, it is just a bit of ugliness for developers, and
shouldn't be that big of a deal.
I'd be fine with that, if there was a real reason for not doing it the
correct way
(We've had some discussion before about "compressing" migrations - i.e.
removing support for migrating from a version of the DB before a certain
version - which would be a better way to get rid of code like this in
the long run)
Cheers,
Mark.