7

I'm seeing a bug/feature in my Ruby 1.9.2 applications. Any changes to views (not ruby files) require a server restart. I initially encountered this in a Rails app, but I've tested the same thing in a minimal Sinatra app too.

I'll include a simple app to demonstrate

# testapp.rb
require 'sinatra'

get '/' do
  [0,1,2].to_s  #change this to [0,1].to_s
end

This is my procedure:

  • ruby testapp.rb (runs thin server for me)
  • load the page
  • open the file and edit the view
  • reload the page (I see no changes)
  • kill the server
  • restart the server (changes now visible)

I've been developing in Ruby 1.8.7 on Rails 3 for the last several months. Having to restart the server on any view change slows down development severely.

I've ready this SO thread, but in my version of Rails (3.1.0 rc4), the config variable is already set as per that answer. Additionally I can replicate the error using Sinatra, so that doesn't seem like it's the case.

Can anyone shed light on this issue?

Ruby version: ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux] Server: thin 1.2.11 (also tested this with Sinatra/Webrick)

EDIT 7/13, Clarification The Sinatra thing is a separate issue--Sinatra's source reloading is disabled by default. I used this code to test out the behavior:

require 'sinatra'
require 'sinatra/reloader'
require 'haml'

set :views, 'views'

get '/' do
end

get '/test' do
  haml :test
end

With this, I made a file: views/test.haml. Modifying it while the server is running does show a change when the page is reloaded. Thanks to Tiredpixel for pointing this out

Unresolved Issue: why does Rails 3.1 on Ruby 1.9.2 not reload the views? I'm able to get ruby files to load, but not haml and erb files. I end up restarting the server just to see if a bug was actually fixed (or not fixed) because of a file not loading properly.

EDIT/SOLUTION (copied from my comment in the accepted answer):

The problem was in config/environments/development.rb

config.cache_classes = false

Even after we checked this was correct, we still had the issue. Further down in the file we had: 

config.threadsafe!

What this does is set the following 3 flags to true: config.allow_concurrency, config.preload_frameworks, and (surprise!) config.cache_classes.

To fix: move config.threadsafe! above config.cache_classes, so that it doesn't get implicitly overridden.

Community
  • 1
  • 1
Eric Hu
  • 18,048
  • 9
  • 51
  • 67
  • 1
    I just created a fresh 3.1.0 rc4 app and [pushed it to github](https://github.com/ezkl/reload_test). It has a controller with a single method and a route. I'm running 1.9.2-p180. When I run `thin start`, browse `http://localhost:3000/`, make changes to `app/views/pages/index.html.erb`, views reload properly. – ezkl Jul 13 '11 at 23:42
  • 1
    Thanks for pushing this. Apparently it was an issue with `config.threadsafe!` writing over `config.cache_classes` – Eric Hu Jul 14 '11 at 00:23

1 Answers1

7

Rails is normally configured to automatically reload on every request, whilst in the development environment. This doesn't happen for files in lib/, though.

The experience you describe with Sinatra is intended (automatic reloading was removed in 0.9.2): http://www.sinatrarb.com/faq.html#reloading; the Shotgun gem can be installed to perform this reloading.

  • Hm, I guess my post was pointing at 2 different issues and I didn't realize it. I'll update it – Eric Hu Jul 13 '11 at 22:54
  • 3
    Have you checked `config/environments/development.rb` `config.cache_classes = false` and `config.action_controller.perform_caching = false` ? –  Jul 13 '11 at 23:26
  • 2
    So this was going down the right path. Someone on my team got it. We already had `config.cache_classes = false` (as well as the other flag you mentioned). However, further down in the file we had: `config.threadsafe!`. What this does is set the following 3 flags to true: `config.allow_concurrency`, `config.preload_frameworks`, `config.cache_classes`. The fix, then, was to move `config.threadsafe!` to above `config.cache_classes`, so that it doesn't get implicitly overridden. – Eric Hu Jul 14 '11 at 00:20
  • Excellent - I didn't know `config.threadsafe!` did that - thanks for the explanation! –  Jul 14 '11 at 01:46