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!
