Rails - Mar 2013 - storing values in session variable vs instance variable

Is there a good practice when to use the session variable. Sometimes I find 
myself using both the session variable and instance variable. For example, 
I have a table that allows a user to select a date. I store the date both 
in the session and in the instance variable. Should I not bother to store 
it in session? In what situations should you use the session variable?

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-talk/-/wT4_mu7jFkMJ.
For more options, visit https://groups.google.com/groups/opt_out.

On 03/18/2013 10:37 AM, John Merlino wrote:
> Is there a good practice when to use the session variable. Sometimes I 
> find myself using both the session variable and instance variable. For 
> example, I have a table that allows a user to select a date. I store 
> the date both in the session and in the instance variable. Should I 
> not bother to store it in session? In what situations should you use 
> the session variable? -- 
The rails session persists across requests while instance variables do 
not.  If you need something in a following request it (or a reference) 
must be in the session.  If you do not need it later I always use an 
instance variable.

Norm

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Norm Scherer wrote in post #1102294:
> On 03/18/2013 10:37 AM, John Merlino wrote:
>> Is there a good practice when to use the session variable. Sometimes I
>> find myself using both the session variable and instance variable. For
>> example, I have a table that allows a user to select a date. I store
>> the date both in the session and in the instance variable. Should I
>> not bother to store it in session? In what situations should you use
>> the session variable? --
> The rails session persists across requests while instance variables do
> not.  If you need something in a following request it (or a reference)
> must be in the session.  If you do not need it later I always use an
> instance variable.
I wouldn''t say that this is precisely accurate. You could continue 
passing a variable from one request to another, and to third, and so on.

Session variables are useful when you really need a value to persist for 
the entire session. I would also say that it''s good practice to use 
session variable sparingly. Session variables are somewhat akin to 
global variables in the sense that they represent globally accessible 
shared state (at least within the context of the current session).

Session variables are also long lived, taking up memory as long as the 
session is kept alive. Although in a Rails application sessions are torn 
down and recreate upon every request, but that might even be worse than 
just leaving them in memory between requests.

Another thing to keep in mind is that by default Rails uses a cookie 
based session storage mechanism, which means sessions have a hard 4K 
limit (cookies are limited to 4K by spec). Another reason to avoid 
putting large amounts of data in the session.

A typical use case for session variable are things like the "id" of
the
current user. Notice I said the "id" not the user object itself.
It''s
better to load the user object when, and only when, necessary. There are 
other great uses for session variables, but think twice about if it''s 
really necessary and try to keep the amount of data as small as 
possible. Remember for every variable in the session is just one more 
thing that has to be loaded from persistent storage on every single 
request.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

instance variables are alive as long as the object instance is alive. My 
question then would be from one http request to the next does the same 
controller instance remain alive? If so, then there''s no need for
sessions
at all. Right?

On Tuesday, March 19, 2013 12:23:44 PM UTC-4, Ruby-Forum.com User
wrote:
>
> Norm Scherer wrote in post #1102294: 
> > On 03/18/2013 10:37 AM, John Merlino wrote: 
> >> Is there a good practice when to use the session variable.
Sometimes I
> >> find myself using both the session variable and instance variable.
For
> >> example, I have a table that allows a user to select a date. I
store
> >> the date both in the session and in the instance variable. Should
I
> >> not bother to store it in session? In what situations should you
use
> >> the session variable? -- 
> > The rails session persists across requests while instance variables do
> > not.  If you need something in a following request it (or a reference)
> > must be in the session.  If you do not need it later I always use an 
> > instance variable. 
>
> I wouldn''t say that this is precisely accurate. You could continue
> passing a variable from one request to another, and to third, and so on. 
>
> Session variables are useful when you really need a value to persist for 
> the entire session. I would also say that it''s good practice to
use
> session variable sparingly. Session variables are somewhat akin to 
> global variables in the sense that they represent globally accessible 
> shared state (at least within the context of the current session). 
>
> Session variables are also long lived, taking up memory as long as the 
> session is kept alive. Although in a Rails application sessions are torn 
> down and recreate upon every request, but that might even be worse than 
> just leaving them in memory between requests. 
>
> Another thing to keep in mind is that by default Rails uses a cookie 
> based session storage mechanism, which means sessions have a hard 4K 
> limit (cookies are limited to 4K by spec). Another reason to avoid 
> putting large amounts of data in the session. 
>
> A typical use case for session variable are things like the "id"
of the
> current user. Notice I said the "id" not the user object itself.
It''s
> better to load the user object when, and only when, necessary. There are 
> other great uses for session variables, but think twice about if
it''s
> really necessary and try to keep the amount of data as small as 
> possible. Remember for every variable in the session is just one more 
> thing that has to be loaded from persistent storage on every single 
> request. 
>
> -- 
> 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 unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-talk/-/WjlpqhZwf88J.
For more options, visit https://groups.google.com/groups/opt_out.

On 20 March 2013 15:41, John Merlino
<stoicism1-YDxpq3io04c@public.gmane.org> wrote:
> instance variables are alive as long as the object instance is alive. My
> question then would be from one http request to the next does the same
> controller instance remain alive?
No.  In addition, once you deploy, you cannot even assume that the
server is still running.  Many systems will shut down the server if it
is idle and re-start it when required.  Also remember that if user A
makes a request then is it common that user B may make a request
before the next request from user A.  So even if the same controller
instance did stay alive the data for the two users would get mixed up.
 Sessions get around this problem.

Colin
> If so, then there''s no need for sessions
> at all. Right?
>
>
> On Tuesday, March 19, 2013 12:23:44 PM UTC-4, Ruby-Forum.com User wrote:
>>
>> Norm Scherer wrote in post #1102294:
>> > On 03/18/2013 10:37 AM, John Merlino wrote:
>> >> Is there a good practice when to use the session variable.
Sometimes I
>> >> find myself using both the session variable and instance
variable. For
>> >> example, I have a table that allows a user to select a date. I
store
>> >> the date both in the session and in the instance variable.
Should I
>> >> not bother to store it in session? In what situations should
you use
>> >> the session variable? --
>> > The rails session persists across requests while instance
variables do
>> > not.  If you need something in a following request it (or a
reference)
>> > must be in the session.  If you do not need it later I always use
an
>> > instance variable.
>>
>> I wouldn''t say that this is precisely accurate. You could
continue
>> passing a variable from one request to another, and to third, and so
on.
>>
>> Session variables are useful when you really need a value to persist
for
>> the entire session. I would also say that it''s good practice
to use
>> session variable sparingly. Session variables are somewhat akin to
>> global variables in the sense that they represent globally accessible
>> shared state (at least within the context of the current session).
>>
>> Session variables are also long lived, taking up memory as long as the
>> session is kept alive. Although in a Rails application sessions are
torn
>> down and recreate upon every request, but that might even be worse than
>> just leaving them in memory between requests.
>>
>> Another thing to keep in mind is that by default Rails uses a cookie
>> based session storage mechanism, which means sessions have a hard 4K
>> limit (cookies are limited to 4K by spec). Another reason to avoid
>> putting large amounts of data in the session.
>>
>> A typical use case for session variable are things like the
"id" of the
>> current user. Notice I said the "id" not the user object
itself. It''s
>> better to load the user object when, and only when, necessary. There
are
>> other great uses for session variables, but think twice about if
it''s
>> really necessary and try to keep the amount of data as small as
>> possible. Remember for every variable in the session is just one more
>> thing that has to be loaded from persistent storage on every single
>> request.
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To view this discussion on the web visit
> https://groups.google.com/d/msg/rubyonrails-talk/-/WjlpqhZwf88J.
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

On Wed, Mar 20, 2013 at 10:48 AM, Colin Law
<clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:
> On 20 March 2013 15:41, John Merlino
<stoicism1-YDxpq3io04c@public.gmane.org> wrote:
>> instance variables are alive as long as the object instance is alive.
My
>> question then would be from one http request to the next does the same
>> controller instance remain alive?
>
> No.  In addition, once you deploy, you cannot even assume that the
> server is still running.  Many systems will shut down the server if it
> is idle and re-start it when required.  Also remember that if user A
> makes a request then is it common that user B may make a request
> before the next request from user A.  So even if the same controller
> instance did stay alive the data for the two users would get mixed up.
>  Sessions get around this problem.
Why hello admin account, how do I love getting it for free :D

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Colin Law wrote in post #1102465:
> On 20 March 2013 15:41, John Merlino
<stoicism1-YDxpq3io04c@public.gmane.org> wrote:
>> instance variables are alive as long as the object instance is alive.
My
>> question then would be from one http request to the next does the same
>> controller instance remain alive?
>
> No.  In addition, once you deploy, you cannot even assume that the
> server is still running.  Many systems will shut down the server if it
> is idle and re-start it when required.  Also remember that if user A
> makes a request then is it common that user B may make a request
> before the next request from user A.  So even if the same controller
> instance did stay alive the data for the two users would get mixed up.
>  Sessions get around this problem.
And even worse than this if you have multiple severs the request #1 from 
user A may go to server #1 and request #2 may go to server #2. If 
controllers remained alive between request then values stored in 
instances variable on server #1 would not be available on server #2.

In Rails sessions are also "persisted" across servers and application 
instances. As I mentioned before sessions are torn down (persisted 
somewhere) and reloaded between every request. It makes not difference 
which instances or server you''re hitting The session is available 
everywhere. There are many options on where to persist session data. 
Cookies (the default), ActiveRecord, Memcachd, etc. In all these cases 
session data must be available to any instance or server wishing to 
access that shared session state.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email
to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.