Class variables in a model are ok to cache relatively static records within the scope of a brower ca

Hi,

Class variables in a model are ok to cache relatively static records
within
the scope of a brower call aren’t they? That is, the results get
“refreshed” effectively each browser call (i.e. per browser call, per
mongrel process). Example of what I’m talking about is below.

@@all_records = nil
def self.all_records
@@all_records ||= Automatch.find(:all) # say only 10 records,
relatively static
end


Greg
http://blog.gregnet.org/

Greg H. wrote:

Class variables in a model are ok to cache relatively static records
within the scope of a brower call aren’t they? That is, the results get
“refreshed” effectively each browser call (i.e. per browser call, per
mongrel process). Example of what I’m talking about is below.

@@all_records = nil
def self.all_records
@@all_records ||= Automatch.find(:all) # say only 10 records,
relatively static
end

Technically yes, and esthetically no.

You are “coupling” the state of your model to its current location in
control
flow. If control flow changes, your coupling might break. If, for
example, you
added a new feature that required two model objects, extant at the same
time,
then their @@all_records might accidentally conflict. Decoupled code is
easier
to safely change - that’s essentially the definition of “decoupled”.

Take out @@all_records = nil entirely, then use @all_records =
Automatch.find(:all). If your controller and similar code is also
decoupled, it
won’t create more instances of your model than it needs, and they will
be efficient.

thanks - that makes sense - interestly enough the code I had, whilst it
worked from the console, didn’t behave the same way from an RSpec
test…anyway I’ll follow your advice

On Tue, Jan 20, 2009 at 3:24 PM, Phlip [email protected] wrote:

@@all_records ||= Automatch.find(:all)      # say only 10 records,

time,


Greg
http://blog.gregnet.org/

On 20 Jan 2009, at 05:03, Greg H. wrote:

@@all_records ||= Automatch.find(:all)      # say only 10  

records, relatively static
end

In development yes, since the class is reloaded. In production no
since the class isn’t reloaded so @@all_record is only ever set once
(minus potential race conditions upon initialization)

Fred