Ruby on Rails Friday, January 27, 2012

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@googlegroups.com.
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.

No comments:

Post a Comment