Where to place the session variable to access it in model

rubyonrails-talk
1

Hi     I have the model SDTicket and SDCi SDTicket has_many :service_desk_cis

SDCi after_save :update_sd_ticket belongs_to :sd_ticket def update_sd_ticket     self.sd_ticket.update_attribute("modified_by_id",#here I need value from session) end

I have a user controller in that session[:id] = current_user_id #here I am setting current user id to session[:id]

     Could you please tell me how I can access this value from SDCi class above in the call back after_save

Thanks in advance Sijo

2

Sijo Kg wrote:

Hi     I have the model SDTicket and SDCi SDTicket has_many :service_desk_cis

SDCi after_save :update_sd_ticket belongs_to :sd_ticket def update_sd_ticket     self.sd_ticket.update_attribute("modified_by_id",#here I need value from session) end

I have a user controller in that session[:id] = current_user_id #here I am setting current user id to session[:id]

     Could you please tell me how I can access this value from SDCi class above in the call back after_save

I can't (personally). I would probably create an instance method in the model inside which I would save the model (self.save) and do other things like update the related model. If you do it this way you could also wrap it in a transaction block to make the whole thing atomic - at least you have that option anyway.

You'd pass the session value in as an argument to this method from the controller; your model shouldn't need to know about where the current_user_id came from (ie someone's http session). This makes things more testable / less coupled.

That's just my thoughts.

3

    self.sd_ticket.update_attribute("modified_by_id",#here I need value

I get the feeling from this line that you are confusing the responsibilities of the Model-View-Controller. Yes, there has been much blogged about skinny controllers and fat models. However, this does not mean you should yank all of the controller's responsibilities away from it.

In my understanding, the calling of "update_attributes" method is a controller responsibility. Yes, it is the model that actually does the updating of the data but the "message' to provide the values to be updated should be sent by a controller. It's also the controller's responsibility to maintain a user's session, so it also has access to the session object.

This is how people get backed into the corner (or fall into the trap) where they begin asking how to access session data in a model. It's the controller's responsibility to decouple the model from the view and controller. When you start mixing these responsibilities is when you get yourself inot trouble.

Sijo Kg wrote:

4

But Sijo needs is justified when tracing "who" is doing something to your model.

Sijo,

look into this screencast from Ryan Bates (http://railscasts.com/ episodes/119-session-based-model). It provides with good leads for a solution on what your looking.

In short what you want to provide your model with is an execution context which will contain the user id (not the whole session).

What you have to keep in mind is to avoid putting anything at the class level since it would prevent your code from bring Threadsafe (which Rails 2.2 is supposed to be).

Jean-Marc Lagacé http://m2i3.com/blog/jean-marc

5

Hi     Thanks for your reply Sijo