Question

I assume this would be the same as enabling the asset pipeline in a project that was created --skip-sprockets – I could be mistaken.

I’m trying to run rake assets:precompile to test, and right now, since I’ve already added require 'sprockets/railtie' to my config/application.rb – it finds the task at least – but it says:

no such table: app_configs

Update: I’ve discovered that this error is coming from a model in our application called AppConfig – so I’m looking into that part. I don’t know why it only happens when running this rake task…

Update: It seems that this particular rake task is assuming I’m in the production environment, even though I’m in my development environment. Other rake tasks don’t seem to have this problem… ? It shows that the task it’s actually running is: /home/.../bin/rake assets:precompile:all RAILS_ENV=production RAILS_GROUP=assets

So it makes sense that it’s not finding the table, because it’s looking in the wrong database (probably one that doesn’t even exist). But how is it determining (incorrectly) that it’s in a production environment?

Answer 1

As it turns out:

I did have the asset pipeline setup almost correctly: all you have to do is run rake rails:update to make sure your project files are all updated to be compatible with your current Rails gem (3.1.x). It will warn you when it’s going to overwrite files and you can view the changes and edit the file yourself (there’s no merge option unfortunately). These changes include several configuration directives specific to the asset pipeline (in the config directory).

One special problem I encountered is addressed by this post: How to build task 'assets:precompile'
– (I was not requiring rails/all, so I had to add the sprockets require)

After doing all this is when I ran into the production environment problem. The assets:precompile task intentionally uses the production environment so that it produces production-ready assets; if you use the development environment it compiles assets according to the configuration in environments/development.rb which generally doesn’t include digest urls. So that’s intentional – the problem then is that when it initializes the production environment, it’s trying to access a database that doesn’t exist in the dev environment. The way to get around that (for testing purposes) is to add this to your config/application.rb file:

config.assets.initialize_on_precompile = false

This prevents it from initializing the app and voila, no more initialization errors during asset pre-compilation 🙂 However: There’s no reason to leave this set to false, unless you intend to precompie all your assets in a non-production environment for some reason (like Heroku does) rather than allowing Capistrano or some other deployment tool to compile them in production when deploying the app. initialize_on_precompile actually lets you use models and other application resources in your asset templates, which can be a useful feature.

Another helpful post: Upgrading from Rails 3 to Rails 3.1