Class variables in action controller

Rails
1

Would someone please help

i scrape the data and want to store in the @@job_list (class variable).
However when I
try to access the class variable from another action, it refers to
another class variable.

is there a way to work with initial grab data to be accessible within
the controller, or do
I have to temporarily store it in the database to use it?

any help would be appreciated.

Nick.B
ex:

class ListingController < ActionController
@@job_list = JobSearch.new

def list
puts @@jobs
@str = params[:search_str]
if @str.nil?
@jobs = nil
else
@jobs =@@jobs.get_all_jobs(@str)
end
end
def index
@search_str = “computer technician”
end

def search
@search_str = params[:search_str]
redirect_to params.merge(:controller=>‘listing’, :action => ‘list’)
end
def sort_by_date
puts @@jobs

@jobs = @@jobs.sort_by_date 

render(:controller => 'listing', :action => 'list')

end
end

2

you might be seeing this behavior if you’re running in development
mode… controllers are reloaded upon every request in development and
test. only in production mode are they loaded just once. class
reloading settings can be changed in the various config/environments/
files i believe

On Sep 25, 11:12 am, Nick B. [email protected]

3

Jeff Emminger wrote:

you might be seeing this behavior if you’re running in development
mode… controllers are reloaded upon every request in development and
test. only in production mode are they loaded just once. class
reloading settings can be changed in the various config/environments/
files i believe

On Sep 25, 11:12 am, Nick B. [email protected]

Thank you very much for that – for a moment I thought I was insane to
think one think and expect another. Would you know where I would change
that value?

4

development.rb. I wouldn’t rely on this: in production mode you will
probably have 2 or more mongrels/fastcgis etc… These independent
processes will of course not share class variables set like that (and
there’s no guarantee as to which mongrel handles a given incoming
request)

Fred

5

Frederick C. wrote:

development.rb. I wouldn’t rely on this: in production mode you will
probably have 2 or more mongrels/fastcgis etc… These independent
processes will of course not share class variables set like that (and
there’s no guarantee as to which mongrel handles a given incoming
request)

Fred
The biggest reason to use class variable, once and object is initialized
– that variable is accessible to it

I am thinking of the solution that once a search is executed from
one_client, i expect that client will interact with result until the new
search is requested or session has expired. I am also am assuming that
each client will create their own session therefore, that that is only
available to that person.

If I am thinking wrong, please help me understand where my mistake is.

Nick. Bhanji. Thanks again.

6

On 27 Sep 2007, at 16:44, Nick B. wrote:

initialized

Those class variables aren’t session specific, they are instance of
mongrel specific. So if you only have one mongrel, then everyone
shares the same one. If there are two or mongrels then it’s a mix:
when you look at the list action it might be handled by the first
mongrel, but when you look at the sort_by_date action then that could
be handled by a different mongrel, with its own copy of @@job_list.

I’m not entirely sure what you’re trying to do but it sounds very
much like class variables are not what you want (database or memcache
or backgroundrb would probably be more suited)

Fred

7

in config/environments/[env].rb

for example, to make development mode cache like production does,
change the values in
config/environments/development.rb to:

config.cache_classes = true
config.action_controller.perform_caching = true

On Sep 27, 10:13 am, Nick B. [email protected]

8

On 27 Sep 2007, at 18:03, Nick B. wrote:

I just found out what you are trying to say. well, how would I solve
the problem that each session has its instance object i.e job_list?

Don’t use class variables. Do use the database, memcache etc…
backgroundrb (at least the old version) also allows you to share a
cache of ruby objects.

Fred

9

Frederick C. wrote:

On 27 Sep 2007, at 16:44, Nick B. wrote:

initialized

Those class variables aren’t session specific, they are instance of
mongrel specific. So if you only have one mongrel, then everyone
shares the same one. If there are two or mongrels then it’s a mix:
when you look at the list action it might be handled by the first
mongrel, but when you look at the sort_by_date action then that could
be handled by a different mongrel, with its own copy of @@job_list.

I’m not entirely sure what you’re trying to do but it sounds very
much like class variables are not what you want (database or memcache
or backgroundrb would probably be more suited)

Fred

I just found out what you are trying to say. well, how would I solve
the problem that each session has its instance object i.e job_list?

Thank you for helping me –

Nick B