Activerecord re-sets class members to null?

I have two classes with class variables. One of them derives from active
record, the other one does not. I initialize both members to NULL, then
lazy-instantiate them. The class which does not derive from active
record preserves the value correctly. The class which does derive from
active record always seems to be re-setting it to NULL.

class Class1 ## @@thelist holds the initialized value

@@thelist = nil
attr_accessor :name, :id

def self.retrieveall
if @@thelist.nil?
@@thelist = Array.new

  entry = Locale.new
  entry.id = "en"
  entry.name = "english"
  @@thelist << entry

  //repeat to populate
end

@@thelist

end
end

class Class2 < ActiveRecord::Base

anytime retrieveall is called @@thelist is always NULL. Why?

@@thelist = nil
attr_accessor :name, :id

def self.retrieveall
if @@thelist.nil?
@@thelist = Class2.all
end

@@thelist

end
end

On Aug 16, 3:48 pm, Tomasz R. [email protected] wrote:

I have two classes with class variables. One of them derives from active
record, the other one does not. I initialize both members to NULL, then
lazy-instantiate them. The class which does not derive from active
record preserves the value correctly. The class which does derive from
active record always seems to be re-setting it to NULL.

Most classes in your app are reloaded between requests. Is this the
problem ?

Fred

On Aug 16, 4:23 pm, Frederick C. [email protected]
wrote:

On Aug 16, 3:48 pm, Tomasz R. [email protected] wrote:

I have two classes with class variables. One of them derives from active
record, the other one does not. I initialize both members to NULL, then
lazy-instantiate them. The class which does not derive from active
record preserves the value correctly. The class which does derive from
active record always seems to be re-setting it to NULL.

Most classes in your app are reloaded between requests. Is this the
problem ?

To clarify, that of course only happens in development

Fred

Most classes in your app are reloaded between requests. Is this the
problem ?

To clarify, that of course only happens in development

Yep, that’s it, thanks. Makes me wonder how I can control which classes
should be reloaded. I’m trying to make something off of development.rb
and production.rb.

On Mon, Aug 16, 2010 at 7:10 PM, Tomasz R.
[email protected] wrote:

Yep, that’s it, thanks. Makes me wonder how I can control which classes
should be reloaded. I’m trying to make something off of development.rb
and production.rb.

Rails comes with 3 development environments already ready to go, look
database.yml. In development and testing, all classes are always
reloaded. In production they are always cached. How is this not
exactly what you want? :slight_smile:


Greg D.
destiney.com | gregdonald.com

On Aug 18, 12:33 am, Tomasz R. [email protected] wrote:

Rails comes with 3 development environments already ready to go, look
database.yml. In development and testing, all classes are always
reloaded.

This does not seem to be true. In my example above, if a class does not
derive from ActiveRecord::Base it preserves its class attributes between
requests, a plausible explanation being that it’s NOT in fact reloaded.

Deriving from activerecord or not should have no incidence. How the
particular class is loaded can influence reloading, the only thing
that you’re likely to do by accident is requiring a file explicitly

Fred

Rails comes with 3 development environments already ready to go, look
database.yml. In development and testing, all classes are always
reloaded.

This does not seem to be true. In my example above, if a class does not
derive from ActiveRecord::Base it preserves its class attributes between
requests, a plausible explanation being that it’s NOT in fact reloaded.

In production they are always cached. How is this not
exactly what you want? :slight_smile:
Very simple. I only would like to be reloading the classes that I’m
currently messing with. Reloading all the classes is a waste of time.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs