Sessions question


#1

Hi, I’m a little confused about sessions. I have two objects, object
“Apple” and object “Banana”. These two objects have an N:M
relationship. What I am doing is listing All of the Banana objects that
are associated with a single Apple, then below that listing all of the
Banana objects not associated with that same Apple. The user is then
allowed to change the associations for this Apple. What I want to do is
to save this information between browsing sessions. I need to do this
for every Apple.

Currently, the Bananas are getting stored in two separate arrays and
being displayed that way. Trying to save these arrays as session
variables has been unsuccesful. If I only had one Apple, I think I
could store that apple with @session[:Apple]? Anyway, any help you can
offer is greatly appreciated. Thanks.


#2

On Thu, Feb 23, 2006 at 10:27:13AM +0100, Kevin M. wrote:
} Hi, I’m a little confused about sessions. I have two objects, object
} “Apple” and object “Banana”. These two objects have an N:M
} relationship. What I am doing is listing All of the Banana objects
that
} are associated with a single Apple, then below that listing all of the
} Banana objects not associated with that same Apple. The user is then
} allowed to change the associations for this Apple. What I want to do
is
} to save this information between browsing sessions. I need to do this
} for every Apple.
}
} Currently, the Bananas are getting stored in two separate arrays and
} being displayed that way. Trying to save these arrays as session
} variables has been unsuccesful. If I only had one Apple, I think I
} could store that apple with @session[:Apple]? Anyway, any help you
can
} offer is greatly appreciated. Thanks.

This looks like a job for a database rather than a job for the session.
Do
you have a strong reason for maintaining it in the session instead?

–Greg


#3

It is maintained in the database, but there will be multiple users
accessing it. I want to keep the base associations in the database but
allow the users to customize their own associations between the objects.


#4

On Thu, Feb 23, 2006 at 04:15:05PM +0100, Kevin M. wrote:
} It is maintained in the database, but there will be multiple users
} accessing it. I want to keep the base associations in the database
but
} allow the users to customize their own associations between the
objects.

This should still be maintained in the database. Ideally, you would use
a
three-way relation. Since Rails doesn’t support that at this time, you
can
do the following instead:

People: id, …
Apples: id, …
Bananas: id, …
BanApples: id, person_id, apple_id, banana_id

Person: has_many :BanApple
BanApple: belongs_to :Person, has_one :Apple, has_one :Banana

So now each person has a list of associations between apples and
bananas.
You can also give the BanApple has_one directives the :include (I think)
directive so its associated Apple and Banana are already loaded. Note
that
I am playing fast and loose with pluralization, but the central idea is
there.

–Greg


#5

On 2/23/06, Kevin M. removed_email_address@domain.invalid wrote:

Hey, thanks for all your help. Assuming that there is potential for a
lot of users, and a large variety of Bananas, would that make database
storage of these elements inefficient?

Well, define “large.”

At some point you’re going to have memory issues if you cram enough
data into your sessions. And what happens if a server goes down? Is
it ok for the users to lose their work if they get logged out?

– James


#6

On Thu, Feb 23, 2006 at 05:21:29PM +0100, Kevin M. wrote:
} Hey, thanks for all your help. Assuming that there is potential for a
} lot of users, and a large variety of Bananas, would that make database
} storage of these elements inefficient?

You can expect the database storage to be more effecient than session
storage. Rails’ lack of support for relations between more than two
tables
winds up costing you a little bit in storage (you have an additional id
column in the relation table that you shouldn’t need), it is still far
more
efficient than storing the same relations in YAML, which is where the
session data goes.

–Greg


#7

Hey, thanks for all your help. Assuming that there is potential for a
lot of users, and a large variety of Bananas, would that make database
storage of these elements inefficient?


#8

I thought all the session information was stored in cookies by default?
Wouldn’t this take the strain off of the server by storing the
information on the client machine?


#9

You hear a lot of people using Memcache for session storing… but, as
James
points out, if a server goes down, sessions are gone. Memcache has a
lot of
big sites using it (LiveJournal, Slashdot…etc)… however, there is no
real “critical” loss if a session all the sudden disappeared.
If you are dealing with sensitive data and processes, I’m assuming DB is
the
way to go ?

The downside of the DB, is the amount of access that happens on large
sites,
where the DB may already be getting hammered enough.

I have no real “heavy” production use of either method personally, but
it
would be interesting to hear some case studies !


#10

On 24/02/2006, at 8:21 AM, Dylan S. wrote:

You hear a lot of people using Memcache for session storing… but,
as James points out, if a server goes down, sessions are gone.
Memcache has a lot of big sites using it (LiveJournal,
Slashdot…etc)… however, there is no real “critical” loss if a
session all the sudden disappeared.
If you are dealing with sensitive data and processes, I’m assuming
DB is the way to go ?

Never store persistent data in a session. Sessions are temporary, use
them for things like login details that can easily be re-entered.

The downside of the DB, is the amount of access that happens on
large sites, where the DB may already be getting hammered enough

Then rethink your database server. The whole point of a relational
DBMS is to handle large volumes of data with many concurrent accesses
and changes. Any RDBMS worth using can support hundreds, possibly
thousands, of concurrent operations given sufficient hardware, and
this should be pretty much any mass-market machine these days.

Any thoughts of ‘Can the DB handle this’ before deployment, or at
least large scale testing, are premature optimisation. Fix it when it
looks like a problem, not when you think it might be one.


Phillip H.
removed_email_address@domain.invalid
http://www.sitharus.com/


#11

But Philip, the app I’m working on is the next eBay, and I only have
enough
money for one server.
Just kidding of course :slight_smile: … and wanted to thank you for those last
paragraphs.
I find myself falling into the premature optimization mindset a
lot

and I’m sure many others do as well :slight_smile:


#12

On 2/23/06, Kevin M. removed_email_address@domain.invalid wrote:

I thought all the session information was stored in cookies by default?
Wouldn’t this take the strain off of the server by storing the
information on the client machine?

The cookie stores the ID of the session. The session itself lives on
the server.

– James