Greetings, I need to explain why carrying around entire objects in the session is a bad idea in Rails. The folks I need to explain this to are relatively new to Rails, coming from a .net background (I personally have no .net experience). I understand the server memory usage problem that stems from storing objects rather than object ids in session. I''m trying to understand whether or not there are additional performance impacts related to transforming session data into ActiveRecord objects. I''ve got a couple of questions, and would be very happy to get any additional information I may not know enough to ask. When Rails receives a request and retrieves the session data, does it unmarshall all of it prior to invoking the action requested? Or does it wait until session data is requested / used by the action? When does Rails create ActiveRecord objects out of the unmarshalled session data? Asked a little differently, maybe better, if I do ... @some_var = session[:some_data] what''s the sequence of steps Rails takes internally to create the @some_var AR object? Is there a difference in performance between creating AR objects from session data vs. creating AR objects from table data? TIA!!! Bill --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Aug 7, 2007, at 4:50 AM, Bill Walton wrote:> Greetings, > > I need to explain why carrying around entire objects in the session > is a bad idea in Rails. The folks I need to explain this to are > relatively new to Rails, coming from a .net background (I > personally have no .net experience). > > I understand the server memory usage problem that stems from > storing objects rather than object ids in session. I''m trying to > understand whether or not there are additional performance impacts > related to transforming session data into ActiveRecord objects. > I''ve got a couple of questions, and would be very happy to get any > additional information I may not know enough to ask. > > When Rails receives a request and retrieves the session data, does > it unmarshall all of it prior to invoking the action requested? Or > does it wait until session data is requested / used by the action?The sessions is unmarshalled before your filters or actions are called.> > When does Rails create ActiveRecord objects out of the unmarshalled > session data? Asked a little differently, maybe better, if I do ... > @some_var = session[:some_data] > what''s the sequence of steps Rails takes internally to create the > @some_var AR object?When the session gets unmarshalled it is rehydrated into the real objects that were stored in the session.> > Is there a difference in performance between creating AR objects > from session data vs. creating AR objects from table data?The base64 endcoding and marshalling can be expensive and it all has to come out of the db anyway. Also problems can arrise when you store AR objects in the sessions. Associated objects and get pulled in and then remain stale or get out of sync with what is in the real db records. I *only* store simple strings, integers, arrays and hashes in the session. It avoids a lot of problems. If you have AR models stored in the sessions and then you deploy new code the old version of the model is in the session and when it gets unmarshaled it can crap out because its not the same version of the class. Basically tell them to only store simple object. It will avoid a ton of pain. Cheers- -- Ezra Zygmuntowicz -- Founder & Ruby Hacker -- ez-NLltGlunAUd/unjJdyJNww@public.gmane.org -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi Ezra, Thank you _very_ much for making the time to reply. I''ll pass the information along. I''m sure it will help. They''re used to .net and I understand the habit''s pretty ingrained in that community, so I don''t expect overnight success, but now I''ve got something I can just remind them to revisit from time to time ;-) Best regards, Bill --~--~---------~--~----~------------~-------~--~----~ 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 Aug 7, 5:57 pm, "Bill Walton" <bill.wal...-xwVYE8SWAR3R7s880joybQ@public.gmane.org> wrote:> Thank you _very_ much for making the time to reply. I''ll pass the > information along. I''m sure it will help. They''re used to .net and I > understand the habit''s pretty ingrained in that community, so I don''t expect > overnight success, but now I''ve got something I can just remind them to > revisit from time to time ;-)Hi Bill, As a longtime .NET developer now using Rails, I can add that the practice of storing objects in session data is a bad idea even in .NET. Marshalling/unmarshalling an object is expensive, and as Ezra pointed out can become "stale". Suppose one object is stored in someone''s browser session and you don''t expire it for a week. Next day you enhance your object and release a new version of your app. User opens their browser, goes to your site, and your app will try to unmarshall an old version of the object. Not good. This would happen in .NET and in Rails (although it''s true, there are some workarounds in .NET that are possible, but are a pain). More and more .NET shops are trying Rails, and I''d be anxious to hear more about your experience so far. Jeff softiesonrails.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 -~----------~----~----~----~------~----~------~--~---
Interestingly, state management in .NET and Rails is something that I debate with my friends all the time. .NET also has another type of state management called view state, where data can be associated with the page or even a specific control on the page, and is then sent back and forth between postbacks. In fact, an ASP.NET page is one big form, so while it is inefficient from a bandwidth perspective, it is quite a handy feature. Incidentally, this feature also enables you to re-sort a list without hitting the DB, which in Rails would require that you implement sorting in JavaScript. Take, for example, a page with an n-tiered menu system. In .NET, the expanded state of each node in the menu system can be stored on that node, so each node will always know how to re-render itself. In Rails, you would have to maintain a list of expanded nodes in the session, in order to re-render a page with everything preserved. I used to dismiss that, arguing that you can AJAX everything in Rails to you never need to re-render a page, but then I got flamed by the accessibility police who kindly pointed out that AJAX has a habit of sending screen readers into a frenzy. Anyway, this is a bit off topic, but interesting nonetheless. Understanding the pros and cons of each platform can only make your own platform better. Cheers, Chris On Aug 8, 8:57 am, "Bill Walton" <bill.wal...-xwVYE8SWAR3R7s880joybQ@public.gmane.org> wrote:> Hi Ezra, > > Thank you _very_ much for making the time to reply. I''ll pass the > information along. I''m sure it will help. They''re used to .net and I > understand the habit''s pretty ingrained in that community, so I don''t expect > overnight success, but now I''ve got something I can just remind them to > revisit from time to time ;-) > > Best regards, > Bill--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi Jeff, Thanks very much for making time to reply. I definitely appreciate it. Hearing from other .net developers will undoubtably make a much larger impression on the team than hearing it from me! As far as experience so far... the team is well intentioned and very impressive wrt what they individually bring to the table. As far as the app itself... I''m from the south. The rule is... ''if you can''t say anything nice...". I know it''ll get better but I think the situation right now is best summed up by a quote from Will Rogers (the humorist, not the TV cowboy, Dale Rogers)... It''s not what we don''t know that hurts. It''s what we know that ain''t true. Thanks again for making the time to reply. I appreciate it very much! Best regards, Bill --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi Chris, Chris wrote:> Interestingly, state management in .NET and Rails is > something that I debate with my friends all the time.There appears to be some of that going on in my team. Debate, I mean ;-) <snip very good stuff>> Anyway, this is a bit off topic, but interesting nonetheless. > Understanding the pros and cons of each platform can > only make your own platform better.I agree whole-heartedly. Thanks very much for making time to add to the fact-base!!! Best regards, Bill --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---