Forum: Ruby on Rails Sessions question

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Kevin M. (Guest)
on 2006-02-23 11:27
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.
Gregory S. (Guest)
on 2006-02-23 15:06
(Received via mailing list)
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
Kevin M. (Guest)
on 2006-02-23 17:15
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.
Gregory S. (Guest)
on 2006-02-23 17:26
(Received via mailing list)
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
Kevin M. (Guest)
on 2006-02-23 18:21
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?
James L. (Guest)
on 2006-02-23 18:54
(Received via mailing list)
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
Gregory S. (Guest)
on 2006-02-23 20:13
(Received via mailing list)
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
Dylan S. (Guest)
on 2006-02-23 21:23
(Received via mailing list)
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 !
Kevin M. (Guest)
on 2006-02-23 23:35
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?
James L. (Guest)
on 2006-02-24 00:01
(Received via mailing list)
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
Phillip H. (Guest)
on 2006-02-24 01:33
(Received via mailing list)
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/
Dylan S. (Guest)
on 2006-02-25 08:55
(Received via mailing list)
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 :) ... 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 :)
This topic is locked and can not be replied to.