Rails - Feb 2007 - Please consider: Session handling too cumbersome and not DRY

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.

2) 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.

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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


--~--~---------~--~----~------------~-------~--~----~
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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---