Inappropriately accesses the database during initialization

[stouset]

In Rails 3, when running rake assets:precompile, Vanity tries to access the production Redis database. It also tries to access the SQL database if model is specified in a a metric. Unfortunately, in an app that runs on Heroku, the production database is never specified and/or accessible from the local console.

I'm not sure exactly why it would be accessing the databases when even ActiveRecord doesn't, but it needs to somehow access the information lazily rather than actively.

[tkharris]

I have this problem as well, and it's a pain. Have to pull vanity out, precompile, then put it back in again :(

[tkharris]

Have a workaround of sorts. see commit https://github.com/tkharris/vanity/commit/03eb846e8fc09b4a3d27f7e26b282e13ae76f1fd in tkharris/vanity where we conditionally init based on an environment variable, then I set that variable in the assets:precompile with a file in lib/tasks:

namespace :assets do
  Rake::Task[:precompile].enhance [:novanity]

  desc "Don't load vanity during assets:precompile"
  task :novanity do
    ENV['NOVANITY'] = '1'
  end
end

This is not a fix really, vanity shouldn't depend on a db connection to assets:precompile, but is convenient for the time being.

[tkharris]

It's interesting that New Relic apparently has the exact same problem, and and very similar solution to their problem was proposed, using ENV['NEWRELIC_ENABLE'] = 'false' in the rakefile.

[eugenijusr]

This worked for me:
config.assets.initialize_on_precompile = false

[phillbaker]

Hi @tkharris and @stouset thanks for reporting this bug. I know that this is quite an old thread, but I've recently joined the contributors to Vanity, and I wanted to let you know that I'll be looking at this bug. Has there been any further movement on workarounds?

Thanks for using Vanity!

[stouset]

Not from my end. As you said, this is quite old. :)

[phillbaker]

I think I'm going to close this issue. As @eugenijusr points out, config.assets.initialize_on_precompile = false is the recommended setting for deploying apps to Heroku: http://guides.rubyonrails.org/asset_pipeline.html#precompiling-assets. Does that solve the issue?

[stouset]

I believe you've misunderstood the problem.

When you precompile assets, you run it in the production environment (regardless of where it is run). Regardless of the Heroku issue, if you do not have a functioning production database configured in database.yml, Vanity will fail as it attempts to access the database.

[phillbaker]

@stouset thanks for following up. I think you're right, I'll reopen.

[phillbaker]

@tkharris thanks for pointing out the new relic example, some links from their repo:

• https://github.com/newrelic/rpm/blob/ac5ce2fccf1bb387f330b48102db9954822f6b53/CHANGELOG#L184 <- changelog explaining usage
• https://github.com/newrelic/rpm/blob/86f7ab7a715d28c95f011371a633ab23e4432fdb/lib/new_relic/agent/autostart.rb#L16 <- link to the singleton, where they check for black listed rake tasks and the environmental variables

[phillbaker]

Sorry, I just want to clarify some thoughts:

1. I definitely see the value in being able to init the vanity gem without needing a datastore connection (redis/db/mongo/etc.). (This also ties somewhat to Graceful operation if redis is down? #11?) I think the New Relic approach of a singleton that can be extended to black list rake tasks and environment variables is a sensible approach, and will probably move forward with that.
2. @stouset I do think the config.assets.initialize_on_precompile = false flag in application.rb is a workaround. Using a config/vanity.yml (thus forcing a db connection), commenting out the production hash in database.yml, config.assets.initialize_on_precompile = false flag in application.rb and running RAILS_ENV=production be rake assets:precompile works for me. Under what circumstances does this workaround fail? Thanks!

[phillbaker]

A config/vanity.yml that turns off collection will allow production servers to run without any persistence at all [1].
/cc @chadwpry

E.g.:

production:
  collecting: false

Alternatively, the mock adapter will allow Vanity to be used with in-memory persistence, so the mock adapter could be used if track! is not called.

production:
  adapter: mock

[1] http://vanity.labnotes.org/configuring.html