#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))
@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.
@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)
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:
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”.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.