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!

On Fri, Jan 27, 2012 at 14:36, rails_digger [email protected]
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 A.: 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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs