I altered a controller to use a session variable in place of an instance
variable, and this happened
Status: 500 Internal Server Error
ActionController::Session::CookieStore::CookieOverflow
In the docs, it does say:
"If you have more than 4K of session data [...] pick another session
store."
What does the phrase "pick another session store" mean? My purpose in
doing this is to keep track of a list assembled by the user. If the
user then chooses a sort option, I need to sort the list as it exists.
AFAIK there are no other ways to doing this. I know nothing about
cookies; does matter how big they are?
Your sessions (by default in cookie) needs to be moved to Active record store or memcache store to fix this issue.
For Databased sessions:
config.action_controller.session_store = :active_record_store
You need to create the session table as below
rake db:sessions:create
rake db:migrate
OR
For Memcache sessions:
config.action_controller.session_store = :mem_cache_store
Also you need to setup a mem cache server and configure it as below
config.cache_store = :mem_cache_store, ‘localhost’, ‘127.0.0.1:11211’, {:namespace => ‘myapp123’}
Yes, you should store simply an array of ID’s, not the entire objects. An ID (integer) is about 4 bytes or so from memory, so it won’t be terribly much information…
Yes, you should store simply an array of ID's, not the entire objects.
An ID (integer) is about 4 bytes or so from memory, so it won't be
terribly much information...
This seems a terrible flaw* to me then: how am I supposed to store this
kind of data? I cannot use a normal global, instance, or class variable
as these could become confused if multiple users are accessing the
service at once. Am I supposed to create a new, temporary per user
database -- and how would I do that?
I guess I could keep track of the search terms that produced the list
instead of the list itself, then when a sort is selected, reapply the
search and then sort.
*but maybe not surprising considering the nature of the html/http beast.
Julian Leviston wrote:
> Yes, you should store simply an array of ID's, not the entire objects.
> An ID (integer) is about 4 bytes or so from memory, so it won't be
> terribly much information...
This seems a terrible flaw* to me then: how am I supposed to store this
kind of data? I cannot use a normal global, instance, or class variable
as these could become confused if multiple users are accessing the
service at once. Am I supposed to create a new, temporary per user
database -- and how would I do that?
Why a per user database? this could be stored in the database
completely normally.
Why a per user database? this could be stored in the database
completely normally.
Fred
Then I will run into the same "simultaneous" user problem. And it is
not data that needs to be kept. Let me flesh this out a bit, as I am
sure other people have dealt with almost identical issues:
The database contains a list of music albums. The user can view a list
of all of them, or they could see a list based on some search criteria
(artist or category). I would like to elaborate on this to allow the
existing list on view to become more highly customized, using drag and
drop, deleting and adding chunks, etc.
By default, the list appears sorted alphabetically by title. But the
user should also be able to re-sort the existing list based on another
criteria -- eg, album length in mb, release date, etc. So rather that
just deliver the list as it is requested using an @instance variable,
I'm keeping it in the session hash. This way, if they click "Sort by
release date", I know what they are looking at and want sorted.
AFAIK it looks like I have two options:
1)Move the session data from cookie to Active Record
2)Use the session data to store the previous search terms rather than
the whole list, meaning reproduce the list and sort it (which I guess is
what I would have done if I had known there was such a tiny limit on the
session store size -- at 20-60 bytes per item, it does not take much of
list to reach 4k. I was working on a "use memory not processor" bias.
I guess that is backward?)
Yes, you should store simply an array of ID's, not the entire objects.
An ID (integer) is about 4 bytes or so from memory, so it won't be
terribly much information...
