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)) -- 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 -~----------~----~----~----~------~----~------~--~---
On 4 Dec 2007, at 20:18, Tom Norian wrote:> > 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> > > 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)) > -- > 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 -~----------~----~----~----~------~----~------~--~---
Frederick Cheung wrote:> On 4 Dec 2007, at 20:18, Tom Norian 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? -- 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 -~----------~----~----~----~------~----~------~--~---
On Dec 4, 2007 2:48 PM, Tom Norian <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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 But personally I would never store anything more than an integer or a simple string in a session. -- Greg Donald http://destiney.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 -~----------~----~----~----~------~----~------~--~---
Greg Donald wrote:> On Dec 4, 2007 2:48 PM, Tom Norian <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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". -- 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 -~----------~----~----~----~------~----~------~--~---