Frederick Cheung wrote:
Why a per user database? this could be stored in the database
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?)