I'm deploying my Rails app on Heroku (Cedar), and there were 3 options about precompiling my assets I could choose from, and I chose the option where Heroku precompiles my assets on deployment.
When I pushed, I got an error that it cannot access my database (during precompiling). So, how to make Rails not connect to the database during precompiling? I don't know why it's set in the first place, because I can't imagine a scenario where precompiling would need access to the database.
I saw somewhere a solution to disable initializing the application on precompiling, which is achieved by adding the following into the application.rb (setting it in the environments/production.rb doesn't work):
config.assets.initialize_on_precompile = false
I tried adding this line, and it works, but I don't know if it is a good solution. Wouldn't this make some plugins you would potentially use for the assets not load during precompiling, thus affecting the end result?
What you're doing is the correct way. If you don't use models / anything else which is actually accessing the database in your assets then you have no need for it. The only time you'd need to have your app initialized is if you were doing things like this: (Completely contrived example, but you can see what I'm getting at)
/* In some css file */
.some_class{
#{User.find(1).avatar_url}
}
If you enable Heroku Labs (http://devcenter.heroku.com/articles/labs-user-env-compile) you can have access to your Db at deployment time which works great.
Do you use Devise? That's usually a culprit for DB access on precompiling assets incidentally.
Related
I am working on rails application , in which i am using ruby 1.9.2 and rails 3.0.8. My application is running quite fine in development environment, which includes creating tables from the application and accessing them.
But when i start my application in production environment in which caching is enabled, every thing is working fine , i am not able to access the table which i am creating using my application. I am able to access these tables after restarting the server, which is a pain.
I am searching for a way where i can clear the cache whenever new table get created, can you please help me to clear the cache dynamically.
Thanks
Naveen Kumar Madipally
The one workaround would be to do this in your environments/production.rb (which is not at all recommended on production)
config.cache_classes = false
this will decrease your performance in production but what you can do is fo to production.rb file and check the blow lines
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
i guess it will solve your problem
There are abstractions for that in ActionDispatch::Reloader : it's what's used in development environment to reload classes.
So basically, you would need to run :
ActionDispatch::Reloader.cleanup!
ActionDispatch::Reloader.prepare!
I'm not sure it would be such a good idea, though, as you can't expect which code (yours or from gems) does things that are supposed to happen only once.
Couldn't you use STI rather than dynamicly creating tables ?
I'm trying to add media query changes to a rails site built with foundation. The server is apache and phusion. However when I make changes to the stylesheet nothing changes on the site.
After I save the changes I'm also doing
touch tmp/restart.txt
in termial and still nothing changes. I imagine it has something to do with rails production. Any way to overwrite this?
Double-check to make sure that your browser hasn't cached everything. So either empty the cache or try a different browser.
If that doesn't work, try running rake assets:clean before each push (whenever you've precompiled locally).
I'm trying to understand what exactly precompiling:assets does, because I've realized that for my last project my CSS would never update when I pushed my app to heroku unless I typed bundle exec rake assets:precompile, but this only started happening towards the end, so I believe I probably added something to the config file.
I'm currently trying to understand caching, which made me think about precompile:assets. Is precompile:assets similar to caching by pre-loading the assets to the web server so that those assets aren't loaded directly from the Rails stack? This is for performance purposes right?
Caching is a related, but separate topic.
The purpose of compiling assets includes the combining and minimizing of assets, e.g. javascript that is all on 1 line with 1 letter variables, as opposed to the originals which are used in development mode and let you debug there using the original source code.
You can find everything you need to know in the Asset Pipeline Rails Guide.
I'm working on a rails app where we want to allow the user to use an admin tool to create new themes. The admin tool is a separate application and communicates with our main application through a database. My problem is that I've written custom Sass extensions to load our data into our style sheets, but once that is done, I am unable to recompile the assets in our production environment.
So far I've seen two possibilities for this:
1.Increment the version of config.assets.version. So I have this code:
MyApp::Application.assets.version =
(MyApp::Application.config.assets.version.to_i + .1)
From what I've read incrementing this should cause the assets to recompile, but it seems to only work when it is incremented by hand and the server is restarted.
2.Create a compiler and tell it to clean up the old assets and recompile them:
compiler = Compass::Compiler.new(
Rails.root.to_s,
Compass.configuration.sass_path,
Compass.configuration.css_path,
{:sass => Compass.sass_engine_options} )
compiler.clean!
compiler.run
With this method, however, I run into the problem that the Sprockets::Index.expire_index! method raises an error when I try to create a new compiler.
Yes, I do understand that I can set the assets to recompile on every request, but the performance hit is not something we want. Also, since this is a theme, the data should not be changing often, so we only need to recompile when the admin chooses to save the new theme.
So, finally, my question is: Are there any other possible methods to do what I want? Or am I going down the right path, and if so, where am I going wrong?
EDIT:
I forgot to mention that since we are using Sass functions to change the values of the stylesheets, even if I do turn on the option to compile in production, it won't work. Since the actual stylesheets will never change.
Rails has a Rake task that does asset compilation for you. You should run it once every time you deploy your application to your production environment.
rake assets:precompile
The compiled assets are output to public/assets. For more details, check out the Rails Asset Pipeline Guide.
Since "upgrading" to Rails 3.1 my app is really slow in development mode
(> 30 per request)
I have a lot of images and it seems most of this time-delay is the asset pipeline processing each GET request for each image.
Don't have this problem in Staging or Production mode as the assets are cached etc.
Is there something I haven't been told or is this how we're expected to work now?
Requests can be slow if you have gems or portions of your app that load code at the start of each request - or that merely reference portions of your app, causing much of it to be loaded. For most of these, the autoloader is the prime cause of request delay.
The rails auto-reloader deletes any autoloadable classes/modules/etc at the start of each request, and can cause significant delays at the beginning of each request as Rails reloads all the source files it needs.
You might want to try playing with https://github.com/wavii/rails-dev-tweaks, which gives you granular control over which requests cause the auto-reloader to kick in. This really isn't a fix of the root cause (something is doing extra work at the start of every request that it probably doesn't need to be doing) - but it certainly mitigates most such issues.
In the meantime:
cp -R app/assets/images public/assets
really helps
remember to add public/assets/* to .gitignore
If your app is slow it is because of your app or one of the gems that you use. I had similar issue and it looks like Mongoid was the case more you can read here:
http://martinciu.com/2011/06/rails-3-1-and-slow-asset-pipeline.html
You can use a rake task:
rake assets:precompile RAILS_ENV=development RAILS_ASSETS_NONDIGEST=true
And as it was mentioned above, don't forget to include public/assets/* to .gitignore