# Please consider: Session handling too cumbersome and not DRY

**URL:** <https://www.ruby-forum.com/t/please-consider-session-handling-too-cumbersome-and-not-dry/87073>\
**Category:** Rails\
**Created:** [February 28, 2007, 12:09am UTC](https://www.ruby-forum.com/t/please-consider-session-handling-too-cumbersome-and-not-dry/87073 "2007-02-28T00:09:38Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![mrstudiocat](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e19adc/32.png) [@mrstudiocat](https://www.ruby-forum.com/u/mrstudiocat)\
**Post date:** [February 28, 2007, 12:09am UTC](https://www.ruby-forum.com/t/please-consider-session-handling-too-cumbersome-and-not-dry/87073/1 "2007-02-28T00:09:38Z")

</div>

Session handling is a bit too cumbersome for my taste in Rails. It seems  
to go against the DRY spirit of Rails. Using sessions feels like being  
back in the PHP world or in some other lesser system.

So what would you think, if

Short version:

1. session (or @session) should always refer to an instance of an  
ActiveRecord object Session. It could have special methods mixed in  
automatically by the system, if needed.

2. It’s bad design to have two different front-ends for data storage,  
the ActiveRecord and the session. So the session data should live in the  
AR model and that specific model could optionally be configured to use  
some other data store. Better to have just one object oriented front-end  
and several back ends, configurable on model by model basis.

Longer version, if I may:

1. Accessing the session data

We have ActiveRecord which is nice. It’s easy to create model  
objects and deal with them. Session, on the other hand, is not  
an AR object. (the thing that you can actually end up saving the  
YAML encoded data into an AR data store doesn’t change the fact.)

So the session data don’t have proper object oriented structure  
like any other AR object in the Rails application do. Instead you  
have to manually put arbitrary strings there through a hash,  
extend existing AR objects to \_dump only the corresponding AR id  
or manually make custom objects serializable by hand in order to  
save them in a session. Sounds like an unnecessary work to me.

It’s not like you didn’t know what data you’re putting in a  
session. Therefore you could as well define the whole session  
thing as a model. Then you could naturally reference other AR  
objects from the session by using :belongs\_to and newcomers would  
never have to be explained why storing serialized objects in the  
session is a bad idea over and over again. It would all be done  
safely and automatically by ActiveRecord. Also you could alter  
the session table as much you’d like without breaking older  
sessions.

1. Implementation is also very much not DRY

I think that people are actively making matters worse by inventing  
different non-AR data stores just for the sessions. Why are they  
doing that?

Well, since the session is not an ActiveRecord by definition,  
people have been forced to come up with several alternative storage  
methods. I see that the intention is good, making performance  
improvements and all that. To my eyes, it’s just bad design.

Instead we should be making alternative backing stores for  
the ActiveRecord! In the Session model, you could then define  
that this model will use the barebones-on-the-metal-superfast-memcache  
backend. Other AR records would use whatever database they were  
already using, or maybe some could take advantage of these new  
different storage methods. It wouldn’t matter that the  
session-optimized AR data stores would be very slow for general  
purpose use since you have a choice.

It’s all about making the thing #1 possible, making programming  
straightforward, intuitive and consistent even with the sessions.  
Also, DRY and the principle of the least surprise apply.

Disclaimer: I’m sorry if this has already been considered for a  
future Rails version but at least I didn’t find anything about it.

---

<div class="post-metadata">

**Author:** ![mrstudiocat](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e19adc/32.png) [@mrstudiocat](https://www.ruby-forum.com/u/mrstudiocat)\
**Post date:** [February 28, 2007, 1:02am UTC](https://www.ruby-forum.com/t/please-consider-session-handling-too-cumbersome-and-not-dry/87073/2 "2007-02-28T01:02:55Z")

</div>

class MySession \< ActiveRecord::Base  
has\_many …  
belongs\_to …  
validates…

class \< self  
def current  
Thread.current[:session]  
end  
def current=(s)  
Thread.current[:seesion] = s  
end  
end

# instance methods

def …  
end  
end

class ApplicationController \< ActionController::Base  
before\_filter :setup\_my\_session

private  
def setup\_my\_session  
MySession.current = session[:my\_session\_id]  
end  
end

helllo.rhtml  
\<%= "Hello #{MySession.current.user.name}! %\>

This is an extreme example but it follows the principle of storing  
object ids in the session and objects the database. You get all the  
benefits of ActiveRecord without the downsides of managing complicated  
session data.

Aaron