Where does RoR store cache_classes code?

In config/environments/production.rb the comment says

Code is not reloaded between requests

config.cache_classes = true
Where does RoR store cache_classes code?

On Jul 23, 2:37 pm, sultan [email protected] wrote:

In config/environments/production.rb the comment says

Code is not reloaded between requests

config.cache_classes = true
Where does RoR store cache_classes code?

That stuff is in ActiveSupport::Dependencies

Fred

Fred, thanks for responding.
What I meant was, where is the cache directory/file physically so I
can delete it.
Or, is there a rake command to clear the cache_classes?
I need to do this so my code changes can be migrated to production.

This post was further to my previous post “Problem with deploying
changes in production.”

In my /config/environment/production.rb, if I have:
config.cache_classes = false
and I run “ruby script/server -e production”
I can see my new changes.

When I change the /config/environment/production.rb back to:
config.cache_classes = true
and kill and restart the server with “ruby script/server -e
production”
the changes are not there. Some how, the old code is still there.

On Jul 23, 8:00 am, Frederick C. [email protected]

You should not be updating code in production while the site is live.

And there’s no “place” for the cache_classes, that’s an “abstract”
configuration, the classes are cached by Ruby itself and you’d have to
unload them to do what you’re looking for but this isn’t a good idea
as there are many side effects.

Maurício Linhares
http://codeshooter.wordpress.com/ | http://twitter.com/mauriciojr

On Jul 23, 4:12 pm, sultan [email protected] wrote:

Mauricio, thanks for responding.
When I restart the server, should it not clear all the cache?

the cache is in memory, so yes. This suggests that your requests
aren’t going where you think they are or you aren’t restarting what
you think you are.

Fred

Mauricio, thanks for responding.
When I restart the server, should it not clear all the cache?

What I am doing now is killing/stopping the server.
Inserting the following line in the controller/action:
stop
to give me an error so I know the server has picked up the change.

I restart the server, and the application works like before.

On Jul 23, 8:39 am, Maurício Linhares [email protected]

Fred, thanks for responding again.

When I have:
config.cache_classes = false
in /config/environment/production.rb
the app stops with the error as expected.

The only change I make is:
config.cache_classes = true
and the old app works, i.e. ignores the “stop” and the actual changes.

Before I make any changes, I kill/stop the server with:
“kill -9 pid”
and after the change I restart with:
“ruby script/server -e production” in both cases.
When I restart, I get:
=> Booting Mongrel
=> Rails 2.3.2 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server

(I have tried both kill -9 pid & Ctrl-C, makes no difference)

Should I be stopping and restarting the server in a different way?

On Jul 23, 9:27 am, Frederick C. [email protected]

I finally figured out the problem.
I have a habit of creating versions of files that I am modifying.
In this case, before I started making the changes, I created x090722-
profiles_controller.rb (copy of profiles_controller.rb) and /model/
x090722-profile.rb (copy of profile.rb).
Depending on the setting of config.cache_classes, the server picked up
the classes from the new or the old versions in a consistent manner.
When I renamed the old versions with .rbkup (from .rb), everything
seems to work.

BTW, this pattern tends to imply that you’re not using source control.
I’d recommend that you find a system that you like (I’m partial to
Git, but others disagree) and start using it as soon as possible.

–Matt J.