Use Railties for initializing plugin

[smoothcontract]

We use this plugin with Rails 3.1 but due to the way the plugin initializes itself we get an error whilst running the 'rake assets:precompile' task on deployment to Heroku.

Essentially the plugin forces ActiveRecord to be loaded during initialization, which in turn forces a database connection to be attempted. This probably doesn't matter that much when deploying elsewhere but Heroku builds a 'slug' with all the precompiled assets - at which point the database connection isn't available.

See: http://devcenter.heroku.com/articles/rails31_heroku_cedar#troubleshooting

If the initialization stuff could be rewritten to use Railties it would work nicely on Heroku. Will_paginate is a nice example of this.

Cheers!

[tonydaly]

• 1 on this issue

[BobWalsh]

is this really the case? See: http://stackoverflow.com/questions/3906323/acts-as-taggable-on-on-heroku and http://stackoverflow.com/questions/4532388/does-acts-as-taggable-on-work-on-heroku

[smoothcontract]

@BobWalsh - The plugin works on Heroku but it breaks the asset precompilation stage (for asset pipeline) of deployment which means Heroku has to fall back to dynamically generated assets which are slower.

This happens if a plugin attempts to load ActiveRecord during initialization (Rails made some changes to minimise this but acts as taggable is still affected). The reference to ActiveRecord forces the DB connection to be attempted - which fails as Heroku hasn't configured the database connection at that stage of the deployment.

If I disable acts as taggable plugin then the assets are precompiled cleanly.

[artemk]

@smoothcontract pull request is welcome.

[smoothcontract]

@artemk Fair enough - I'll give it a go when I get some time available

[WizardOfOgz]

I'm using a hack to work around the issue with act as taggable until it is fixed.

acts_as_taggable rescue nil # HACK: there is a known issue that acts_as_taggable breaks asset precompilation on Heroku.

[dwaynemac]

+1 on this and
@WizardOfOgz , where do you put that line?

[chalofa]

+1 with the problem (and also the work around, thanks @WizardOfOgz )

[WizardOfOgz]

@dwaynemac I use that in each model that I want to make taggable

[urkle]

from the Ruby on Rails guides they mention a workaround for the heroku issue with some gems

http://guides.rubyonrails.org/asset_pipeline.html#precompiling-assets

Basically you set config.assets.initialize_on_precompile to false.

[tilsammans]

Would this problem be fixed if this plugin is moved to an engine structure?

[eamo]

+1 With problem (and the workaround is not working on Rails 4.0.0rc1)

[trappist]

+1 on the problem and the workaround on 4.0.0

[dcabo]

+1 on this. Just ran into this issue deploying a Rails 4.0 / Ruby 2.0 app onto Heroku. The config.assets.initialize_on_precompile setting doesn't fix it, but enabling an Heroku Labs experimental feature does: heroku labs:enable user-env-compile. More info.

[jcamenisch]

Would it not be better to use acts_as_taggable if connection.active? rather than eating all exceptions with rescue nil?

Note: I haven't tested this yet; just wondering if someone here has a reason for ruling that out.

[ericboehs]

I tried several different combinations of checking if the connection was present/active. Unfortunately this doesn't work:
acts_as_taggable if -> { defined?(ActiveRecord::Base) and ActiveRecord::Base.connection.active? }

I guess for now I'm justing going to rescue nil and pray all is well.

[jcamenisch]

Well, I guess we have our answer.

Maybe you should post a comment on the acts_as_taggable thread just to keep
someone else from trying all that stuff.
On Aug 7, 2013 11:43 PM, "Eric Boehs" notifications@github.com wrote:

I tried several different combinations of checking if the connection was
present/active. Unfortunately this doesn't work:
acts_as_taggable if -> { defined?(ActiveRecord::Base) and
ActiveRecord::Base.connection.active? }

I guess for now I'm justing going to rescue nil and pray all is well.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/192#issuecomment-22301604
.

[jackdempsey]

hey folks, FWIW you can prevent this issue without a blanket rescue nil by doing:
unless ARGV.join.include? 'assets:precompile'
acts_as_taggable_on
end

[ericboehs]

Thanks! Nicer hack!

On Thu, Aug 29, 2013 at 10:35 PM, jack dempsey notifications@github.com
wrote:

hey folks, FWIW you can prevent this issue without a blanket rescue nil by doing:
unless ARGV.join.include? 'assets:precompile'
acts_as_taggable_on

end

Reply to this email directly or view it on GitHub:
#192 (comment)

[jcamenisch]

Indeed

[Linuus]

@jackdempsey That doesn't work for me as it seems to choke when Heroku does assets:clean instead. Had to go for rescue nil for now :(

[adamrubin]

@Linuus Just do something like:

  unless (ARGV.join.include? 'assets:precompile') || (ARGV.join.include? 'assets:clean')
    acts_as_taggable_on :foo
  end

[anatomic]

@adamrubin and @jackdempsey Thanks for posting your updated ways around this, it's been bugging me for the last couple of days!

[markburns]

  unless (ARGV & ['assets:precompile', 'assets:clean']).any?
    acts_as_taggable_on :foo
  end

[rcuyegkeng]

@markburns Thanks for providing a workaround for this problem.

[markburns]

@rcuyegkeng I can't take credit - I just reworded @adamrubin 's solution

[bf4]

Should be fixed by #438