config.action_controller.session_store = :active_record_store
So that gets me sessions as ActiveRecords. Seeing as I get
updated_at for free, do I also get everything else with ActiveRecord as well? Associations? Callbacks? yada yada. If so how do I start using them?
Let me give you an example. It’s best-practice to store object ids rather than the objects themselves in session variables. That’s all well and good because you can always do
instance = Object.find(session[:object_id])
and process the instance as needed. Of course, session data is intended to be temporary. Now using the above code to obtain an instance, you can then do
and if your object also has dependent objects through associations, then the proper callbacks will take care of destroying the children as well.
Now here’s where it get’s tricky. What if the user agent does not call the action to manually destroy the instance? The session will expire and your cron job will clean out the session table dutifully except the data to which the session pointed lingers. Hence my question about associations and callbacks.
Could you, for example, create a before_destroy call back to destroy the object (and children) before destroying the session?
Coud you instead create a (two-way) dependent association between a session record and an object? This would enable things like:
session.object = an_object or
an_object.session.create (this statement makes more sense)
either of which implies
Because the association is dependent, if the session gets destroyed (via an action or cron job) the associated object is automatically destroyed as well. If the object gets destroyed, the session is nullified or destroyed.
So am I loony for thinking that Rails has(/should have) this automated mechanism already or am I stuck doing my own manual record keeping?