Rails - Jan 2009 - class variables in a model are ok to cache relatively static records within the scope of a brower call aren't they???

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/

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.


--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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
<phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 20 Jan 2009, at 05:03, Greg Hauptmann wrote:
> 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
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
>
>
>
> -- 
> 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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---