[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Class variables in Ruby

Paul

8/18/2006 7:28:00 PM

Hello all,

I am trying to cache lookup table values from a database table into a
hash that is stored in a class variable. This will allow me to read and
store the id/descr value pairs from the database one time only after
which I store them in the hash and retrieve them from there.

The problem is the class variable appears to be cleared out each time a
new request comes in to my controller. I am using rails in the
development enrionment but I am hoping this is a Ruby issue. I thought
maybe rails was reloading the class each time a request comes in
because I read this is standard behavior in the development
environment. However, I believe the reloadable? method is supposed to
care of that?

Here is the code from my model class. The code is alwasy going to super
to read from the database. If anyone can steer me straight on this I
would appreciate it!

Thanks in advance.
Paul

class GrammarTenseCode < ActiveRecord::Base
has_many :words
@@cachedDescr = {}

def self.reloadable?
false
end

def descr
if @@cachedDescr[id.to_s] == nil
@@cachedDescr[id.to_s] = super
else
@@cachedDescr[id.to_s]
end
end
end

20 Answers

khaines

8/18/2006 7:46:00 PM

0

Daniel Waite

8/18/2006 8:34:00 PM

0

> @@cacheDescr = {} unless @@cacheDescr

Or, to be more idiomatic:

@@cache_descr ||= {}



--
Posted via http://www.ruby-....

khaines

8/18/2006 9:24:00 PM

0

Paul

8/18/2006 10:05:00 PM

0


khaines@enigo.com wrote:
> On Sat, 19 Aug 2006, Paul wrote:
>
> > @@cachedDescr = {}
>
> If you think reloading is happening, try:
>
> @@cacheDescr = {} unless @@cacheDescr
>
>
> Kirk Haines

Hi Kirk,

I tried @@cacheDescr = {} unless @@cacheDescr but I get the same
results. I would expect the initialization of @@cacheDescr to take
place when the .rb package is loaded. I will keep playing with it and
post a solution when I figure it out.

Thanks,
Paul

Ara.T.Howard

8/19/2006 1:49:00 AM

0

Paul

8/19/2006 2:03:00 AM

0

SOLUTION: Rails, in the development environment, was reloading the
class for every request coming into the application and therefore
causing the Class variable to be reset. Something I read led me to
believe I could add the following method to my class to cause it not to
be reloaded

def self.reloadable?
false
end

That was false. To keep rails from reloading the class every time you
can change the ..\config\environments\development.rd file. It has a
"config.cache_classes = false" line that you can change to <true>
which will prevent the classes from being reloaded. You are REQUIRED to
stop the WEBrick server though to pick up this change as well as
whenever to want to pick up any recent coding changes. BUT, you can
change this parameter temporarily to test out Class variables that are
expected to store data throughout your session. Don't forget to change
it back to <false> to be back in the default mode which is the
desirable mode for development.

James Gray

8/19/2006 4:15:00 AM

0

On Aug 18, 2006, at 9:05 PM, Paul wrote:

> To keep rails from reloading the class every time you
> can change the ..\config\environments\development.rd file.

You really, really don't want to do this. Trust me. ;)

You've already noted that this makes development mode suck. If you
go this way, you will need to toggle the setting every time you need
it to work or go without Rails's best development feature. Ouch.

That should be reason enough, but it gets worse!

Depending on how you deploy your application, it's quite likely you
could have two or more separate interpreters running your production
code. These will *not* share class variables. This is the way of
pain and could be a source of all kinds of nasty issues.

If you need to remember a value in Rails it needs to be in the
database or the session.

James Edward Gray II


Ara.T.Howard

8/19/2006 5:28:00 AM

0

Paul

8/19/2006 3:58:00 PM

0

James,

Thanks for the comments. I am coming from a Smalltalk background and we
would typically cache code/description lookup table rows into a class
variable for performance. That is, when we wanted to look up a
description we would check the cache first and then hit the database
only if it had not been retrieved yet.

In this scenario, it's not a problem if the cache is maintained
individually over separate instances of the interpreter. This way every
user benefits from the cache rather than storing it in a session unless
I misunderstand the life cycle of class variables. I would think they
would live until the class is reloaded.

However, I do see your point and agree and that under most application
situations this would not be the way to go.

Thanks,
Paul


James Edward Gray II wrote:
> On Aug 18, 2006, at 9:05 PM, Paul wrote:
>
> > To keep rails from reloading the class every time you
> > can change the ..\config\environments\development.rd file.
>
> You really, really don't want to do this. Trust me. ;)
>
> You've already noted that this makes development mode suck. If you
> go this way, you will need to toggle the setting every time you need
> it to work or go without Rails's best development feature. Ouch.
>
> That should be reason enough, but it gets worse!
>
> Depending on how you deploy your application, it's quite likely you
> could have two or more separate interpreters running your production
> code. These will *not* share class variables. This is the way of
> pain and could be a source of all kinds of nasty issues.
>
> If you need to remember a value in Rails it needs to be in the
> database or the session.
>
> James Edward Gray II

Gary Wright

8/19/2006 4:29:00 PM

0


On Aug 19, 2006, at 12:00 PM, Paul wrote:
> Thanks for the comments. I am coming from a Smalltalk background
> and we
> would typically cache code/description lookup table rows into a class
> variable for performance.

Just a side note. It isn't necessary to use class variables to
accomplish your goal. A plain old instance variable of the class object
is just fine. I'm not a big fan of Ruby class variables. I think they
are often used simply because they are confused with instance variables
of a class object.

Gary Wright