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: > > Greg Hauptmann 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. > > > > > -- Greg http://blog.gregnet.org/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
