when to save, session reflect saves?

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?

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

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

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

Greg Donald 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..

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