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
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
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
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)