# When to save, session reflect saves?

**URL:** <https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136>\
**Category:** Rails\
**Created:** [December 4, 2007, 9:18pm UTC](https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136 "2007-12-04T21:18:53Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [December 4, 2007, 9:18pm UTC](https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136/1 "2007-12-04T21:18:53Z")

</div>

I am trying to clean up unnecessary lines (even as I hack my way forward  
adding more garbage)

I have two questions on lines I have trying to keep the database and  
session info reflecting changes:

def associate\_pupil\_to\_teacher  
@teacher = session[:teacher]  
@pupil = Pupil.find(params[:id])  
@teacher.pupils \<\< @pupil  
@teacher.save#Q1  
session[:teacher] = @teacher#Q2  
end

#Q1 do i need to do a save or is the objected reffered to by @teacher  
automatically saved when association is augmented?

#Q2 if I want the @teacher object in session to reflect the current  
association do I need to put the newly saved @teacher object back into  
session? Is the session a pointer to an object or a separate store of  
data?

Thanks in advance… (I am suspecting that I can bag the save but need  
to refresh the session information but I’m curious whether I should do a  
save for good measure, whether an extra save is wasteful, badform,  
slovenly yada yada (same with session))

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [December 4, 2007, 9:30pm UTC](https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136/2 "2007-12-04T21:30:51Z")

</div>

On 4 Dec 2007, at 20:18, Tom N. wrote:

> @pupil = Pupil.find(params[:id])  
> session? Is the session a pointer to an object or a separate store of  
> data?

The save is unnecessary: the only record that gets altered by adding a  
pupil is the pupil (since teacher\_id has to be set) if you’ve got a  
has\_many, or a record in the join table if you’re got hatbm or  
has\_many :through. The session is also unnecessary. session[:teacher]  
= @teacher doesn’t even do anything since session[:teacher] is already  
@teacher.

On a side note, putting model objects in the session is usually a bad  
idea.

Fred

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [December 4, 2007, 9:48pm UTC](https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136/3 "2007-12-04T21:48:57Z")

</div>

Frederick C. wrote:

> On 4 Dec 2007, at 20:18, Tom N. wrote:
> 
> > @pupil = Pupil.find(params[:id])  
> > session? Is the session a pointer to an object or a separate store of  
> > data?
> 
> The save is unnecessary: the only record that gets altered by adding a  
> pupil is the pupil (since teacher\_id has to be set) if you’ve got a  
> has\_many, or a record in the join table if you’re got hatbm or  
> has\_many :through.

Ah, ok. so when an Object has a “has\_many” relationship the rows in the  
join table aren’t really a part of the parent object, the parent object  
only knows where to look at the join table (and i will see whatever is  
there when it looks)? thanks

The session is also unnecessary. session[:teacher]

> = @teacher doesn’t even do anything since session[:teacher] is already  
> @teacher.

I guess session is a pointer, not a separate record.

> On a side note, putting model objects in the session is usually a bad  
> idea.

OH DEAR!!

I absolutely need to keep track of a number of model objects that are  
“selected” at any given time to produce “state”.

Should I be doing things like

@teacher = Teacher.find\_by\_id(session[:teacher\_id]) if  
session[:teacher\_id]

instead of

@teacher = session[:teacher]

It feels so much cleaner just storing the object in session and  
(seemingly) avoiding a “find” . (find’s seem to get all pesky about  
nil objects)

What is the danger of storing objects in session?

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [December 5, 2007, 12:08am UTC](https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136/4 "2007-12-05T00:08:00Z")

</div>

On Dec 4, 2007 2:48 PM, Tom N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> What is the danger of storing objects in session?

Sessions are a way to persist objects across requests. But if you  
stop to think about it, your data is already persistent because it’s  
stored in the database. So rather than store the data again in a  
session (and run the risk of it becoming stale) you would normally  
just store an id to the data in your session, then only bring the data  
into memory on request.

The world won’t end if you store actual objects in a session… you  
might even find some docs floating around the 'net doing just that:

[http://wiki.rubyonrails.org/rails/pages/UnderstandingSessions](http://wiki.rubyonrails.org/rails/pages/UnderstandingSessions)

But personally I would never store anything more than an integer or a  
simple string in a session.

–  
Greg D.  
[http://destiney.com/](http://destiney.com/)

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [December 5, 2007, 2:37am UTC](https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136/5 "2007-12-05T02:37:35Z")

</div>

Thank you both.

It sounds like the more verbose way of using object ids, then retrieving  
the object by id is the way things are done.

For someone new to this, it kinda feels like storing your water bottle  
in your pack while hiking and needing to take the pack off, unzip it  
take the bottle out, every time you want a drink… I just want a  
handful of state holding object variables ever ready! (but I guess they  
are there for the finding and re-finding with their id’s)

I have too many things spinning in my head to try to begin to understand  
exactly what caching is at the moment. (do I need to?)

I’m guessing that my idea of a web app is sorta pushing the limits of  
using a web interface to do things that would work way faster if done by  
a program entirely on a user’s PC…so incremental bits of time would  
matter as the user will be irritated by every bit of delay between click  
and screen updates. I don’t think forcing them to login again every now  
and then would be a problem.(If i wiped database stored session info  
with each change I made to models).

But I certainly don’t want to build another layer of maintenance  
concerns that might come from caching gone a muck. Thanks for pointing  
out the mistake I was making with my perceived “short-cut”.

---

<div class="post-metadata">

**Author:** ![tomn](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/c89c15/32.png) [@tomn](https://www.ruby-forum.com/u/tomn)\
**Post date:** [December 5, 2007, 1:10am UTC](https://www.ruby-forum.com/t/when-to-save-session-reflect-saves/122136/6 "2007-12-05T01:10:33Z")

</div>

Greg D. wrote:

> into memory on request.
> 
> The world won’t end if you store actual objects in a session…

But your application will… on the first code update where the classes  
of the objects stored in session will be modified…  
The user’s session won’t be able to be loaded (the unmarshalling will  
raise errors when inconsistencies between the object loaded and it’s  
class are detected), leading to nasty errors reported to the users. If  
you use the cookiestore, this probably will be a nightmare (never used  
it so you’d better check it for yourself): you’ll have to either contact  
all your users to tell them to delete their cookies or modify the Rails’  
session code to detect these cases and replace the session (last time I  
looked it didn’t do it). For the other stores, simply wiping them is the  
solution (your users will have to login again, but it’s the minimum  
price).

If you store ids you don’t have this problem. If you think you’d better  
store objects in session for performance reasons (I’ve read this  
argument several times), think again: doing this you are creating a  
cache of objects, no more, no less. It will bring the usual cache  
problems, so you’d better do it right, study the subject if you are not  
familiar with its problems and solutions and create a real cache using  
MemCache for example (or look at all the ActiveRecord caches already  
coded out there).

Lionel