Rails - Jan 2012 - Are class variables a good way to set the context for a class instance in Rails?

Hi!

I''ve kind of gotten desperate trying to figure out if there''s
a safe/
good way to set the context for a class instance. I suppose if my
Rails application was running single threaded this wouldn''t be a
problem, but if I end up deploying it multi-threaded I could be for a
world of hurt.

I''m building a rails app that managed Member of a Group. There is a
Member model and a Group model. Since a Member can belong to many
Groups, and a Group can have many Member , there is a HABTM
association between them.

The question I''m having is determining the Group context in which a
Member instance exists. For example, to set a Member''s dues status as
"paid", I need to know which Group the dues have been paid for. The
implementation should look something like this:

@member.paid=true

Without having to remember and set the Group everytime the Member''s
paid status is updated.

The test code I wrote sets the current_group class variable in Member
from the ApplicationController:

class ApplicationController < ActionController::Base
  ...
  before_filter :set_current_group

  def set_current_group
    Member.current_group = current_group
  end
  ...
end

This would assign the current_group variable to the Member. In the
Member model the current_group class attribute could be accessed and
reflect the correct Group from a Member object in a Controller or
View:

class Member < ActiveRecord::Base

  cattr_accessor current_group
  ...
  def paid=(status)
    if (status)
      @@current_group.paid_members << self
    else
      @@current_group.paid_member.delete(self)
    end
  end

  def paid?
    @@current_group.paid_members.include?(self)
  end
  ...
end

In a Controller I could refer to the paid status from the added Member
method:

if @member.paid
  # Do something
end

For in a View I could loop through all Member and display which ones
have paid: (not a great example)

<% @members.each do |member| %>
  <%= member.name %> payment status:
  <% if member.paid %>Paid<% end %>
<% end %>

The concern is, after testing this out on WebBrick, a single threaded
runtime environment will maintain the Group context for the session,
but with a Multi-threaded runtime the Group context may be reset
between requests. I don''t want to run into an issue with different
user''s logging in and the paid status being nil or worse, seeing
someone else''s information.

Can someone please shed some light on this? I''m having a hard time
digging up good information on how the application context is shared
between request sessions. If I move to a multi-threaded environment,
the ApplicationController context for the last request and the new
thread request shouldn''t be shared.

Finally, I know that I can write the Member.paid() method to take a
Group, then return the paid status. It just seems really ugly to have
to carry the current_group round and manually pass it into the paid
method each time. I''m just trying to simplify the implementation of
paid(), while at the same time understand session context with Rails.

Thank you for anything anybody can provide!

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

On Fri, Jan 27, 2012 at 14:36, rails_digger
<chris-CTDZInX59jeukZHgTAicrQ@public.gmane.org> wrote:
> I''m building a rails app that managed Member of a Group. There is
a
> Member model and a Group model. Since a Member can belong to many
> Groups, and a Group can have many Member , there is a HABTM
> association between them.
Using HMT (has_many :through) rather than HABTM will make your whole
problem go away, with no need for worrying about threading, object
context, etc.  (At least, any more than usual!)

Try using an association table, to represent a given member''s
membership (hey, sounds like a good class name there!) in a group.
That''s where you can put info like whether they''re current on
their
dues *for that group*, when they joined *that group*, etc. etc. etc.

-Dave

-- 
Dave Aronson:  Available Cleared Ruby on Rails Freelancer
(NoVa/DC/Remote) -- see www.DaveAronson.com, and blogs at
www.Codosaur.us, www.Dare2XL.com, www.RecruitingRants.com

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