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. -- Posted via http://www.ruby-forum.com/.
On Thu, Feb 23, 2006 at 10:27:13AM +0100, Kevin Mehlbrech 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
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. -- Posted via http://www.ruby-forum.com/.
On Thu, Feb 23, 2006 at 04:15:05PM +0100, Kevin Mehlbrech 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
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? -- Posted via http://www.ruby-forum.com/.
On 2/23/06, Kevin Mehlbrech <mynock51@gmail.com> 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
On Thu, Feb 23, 2006 at 05:21:29PM +0100, Kevin Mehlbrech 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
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 ! On 2/23/06, Gregory Seidman <gsslist+ror@anthropohedron.net> wrote:> > On Thu, Feb 23, 2006 at 05:21:29PM +0100, Kevin Mehlbrech 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 > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060223/6aa0eb7a/attachment.html
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? -- Posted via http://www.ruby-forum.com/.
On 2/23/06, Kevin Mehlbrech <mynock51@gmail.com> 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
On 24/02/2006, at 8:21 AM, Dylan Stamat 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 enoughThen 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 Hutchings phillip.hutchings@sitharus.com http://www.sitharus.com/
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 :) On 2/23/06, Phillip Hutchings <sitharus-rails@sitharus.com> wrote:> > > On 24/02/2006, at 8:21 AM, Dylan Stamat 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 Hutchings > phillip.hutchings@sitharus.com > http://www.sitharus.com/ > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060225/76e997f6/attachment.html