Hi,
I am new to Ruby on Rail. I have a question regarding the one_to_many
relationship which doesn''t automatically update the relationship by
Rails.
Support I have two classes: Car and Wheel.
Car has many Wheel where as Wheel belongs to Car. Therefore, I declare
the classes as below:
// car.rb
class Car < ActiveRecord::Base
has_many :wheels
end
// wheel.rb
class Wheel < ActiveRecord::Base
belongs_to :car
end
The is how I test drive in rails console:
car1 = Car.new
car1.save
car2 = Car.new
car2.save
wheel1 = Wheel.new
wheel1.save
wheel2 = Wheel.new
whee2.save
car1.wheels << wheel1
car1.wheels << wheel2
car2.wheels << wheel2
Note that car1 wheels STILL contains wheel2 when I reassign wheel2 to
car2.
I expect car1 doesn''t have wheel2 anymore...
I don''t know why it doesn''t get update automatically that car1
shouldn''t
contains wheel2 anymore. Can anybody help me to solve this problem?
Thanks.
--
Posted via http://www.ruby-forum.com/.
--
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
On 27 November 2011 21:27, kahou l. <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Hi, > > I am new to Ruby on Rail. I have a question regarding the one_to_many > relationship which doesn''t automatically update the relationship by > Rails. > > Support I have two classes: Car and Wheel. > > Car has many Wheel where as Wheel belongs to Car. Therefore, I declare > the classes as below: > > // car.rb > class Car < ActiveRecord::Base > has_many :wheels > end > > // wheel.rb > class Wheel < ActiveRecord::Base > belongs_to :car > end > > The is how I test drive in rails console: > > car1 = Car.new > car1.save > > car2 = Car.new > car2.save > > wheel1 = Wheel.new > wheel1.save > > wheel2 = Wheel.new > whee2.save > > car1.wheels << wheel1 > > car1.wheels << wheel2 > car2.wheels << wheel2 > > Note that car1 wheels STILL contains wheel2 when I reassign wheel2 to > car2. > I expect car1 doesn''t have wheel2 anymore... > > I don''t know why it doesn''t get update automatically that car1 shouldn''t > contains wheel2 anymore. Can anybody help me to solve this problem?Try fetching car1 from the database again, I suspect it is just that the version in memory does not know that you have removed one of its wheels. I think there is a way of asking it to refresh itself to save explicitly fetching it, but I cannot bring it to mind at the moment. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Thanks, It works if I fetch it to the memory again! Just wonder if there is such a way that it can refresh itself in the memory? -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 27 November 2011 21:56, kahou l. <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Thanks, > > It works if I fetch it to the memory again! > > Just wonder if there is such a way that it can refresh itself in the > memory?It is very rarely an issue in a real app. Remember objects typically only have a very short life cycle as they only exist for a single http request. I am not saying that it is never an issue, but only rarely. Colin> > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- gplus.to/clanlaw -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Sun, Nov 27, 2011 at 16:27, kahou l. <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> car1.wheels << wheel1 > > car1.wheels << wheel2 > car2.wheels << wheel2 > > Note that car1 wheels STILL contains wheel2 when I reassign wheel2 to > car2. > I expect car1 doesn''t have wheel2 anymore... > > I don''t know why it doesn''t get update automatically that car1 shouldn''t > contains wheel2 anymore. Can anybody help me to solve this problem?Interesting. What''s *supposed* to happen is that wheel''s car_id gets set to the id of the car. When you do that the second time, that *should* overwrite the first one, so that the first one''s wheels would no longer include it. Why that''s not happening, I''m not sure. Just tried it with one of my own apps, that has Decisions that belong to Users. Transcript: ruby-1.9.3-head :005 > u1 = User.new => #<User id: nil, other details snipped> ruby-1.9.3-head :006 > u1.id = 1001 => 1001 ruby-1.9.3-head :007 > u2 = User.new => #<User id: nil, other details snipped> ruby-1.9.3-head :008 > u2.id = 1002 => 1002 ruby-1.9.3-head :009 > d = Decision.new => #<Decision id: nil, user_id: nil, other details snipped> ruby-1.9.3-head :020 > d.id = 1000 => 1000 ruby-1.9.3-head :010 > u1.decisions << d => [#<Decision id: 1000, user_id: nil, other details snipped>] ruby-1.9.3-head :011 > u2.decisions << d => [#<Decision id: 1000, user_id: nil, other details snipped>] ruby-1.9.3-head :016 > d => #<Decision id: 1000, user_id: nil, other details snipped> ruby-1.9.3-head :021 > u1.decisions => [#<Decision id: 1000, user_id: nil, other details snipped>] ruby-1.9.3-head :022 > u2.decisions => [#<Decision id: 1000, user_id: nil, other details snipped>] How odd, user_id stays nil! Given that, I''m not sure just how Rails "knows" that u#.decisions includes d. If anyone here has a clue, maybe that would clear things up. Meanwhile, as Colin said, Rails objects usually have a very short lifespan, so maybe the fact that it was in the console, rather than over the course of a bunch of HTTP requests, could have something to do with it. Maybe something gets set when Rails set up or tears down a request object, that isn''t happening here. Try making an app in which you can CRUD cars and wheels, put wheels on cars, and take wheels off cars. Let us know what happens when you try to do the same thing through the app. -Dave -- LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern languages. Where: Northern Virginia, Washington DC (near Orange Line), and remote work. See: davearonson.com (main) * codosaur.us (code) * dare2xl.com (excellence). Specialization is for insects. (Heinlein) - Have Pun, Will Babble! (Aronson) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On 27 November 2011 22:34, Dave Aronson <googlegroups2dave-BRiZGj7G2yRXqviUI+FSNg@public.gmane.org> wrote:> On Sun, Nov 27, 2011 at 16:27, kahou l. <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote: > >> car1.wheels << wheel1 >> >> car1.wheels << wheel2 >> car2.wheels << wheel2 >> >> Note that car1 wheels STILL contains wheel2 when I reassign wheel2 to >> car2. >> I expect car1 doesn''t have wheel2 anymore... >> >> I don''t know why it doesn''t get update automatically that car1 shouldn''t >> contains wheel2 anymore. Can anybody help me to solve this problem? > > Interesting. What''s *supposed* to happen is that wheel''s car_id gets > set to the id of the car. When you do that the second time, that > *should* overwrite the first one, so that the first one''s wheels would > no longer include it. Why that''s not happening, I''m not sure. Just > tried it with one of my own apps, that has Decisions that belong to > Users. Transcript: > > ruby-1.9.3-head :005 > u1 = User.new > => #<User id: nil, other details snipped> > ruby-1.9.3-head :006 > u1.id = 1001 > => 1001 > ruby-1.9.3-head :007 > u2 = User.new > => #<User id: nil, other details snipped> > ruby-1.9.3-head :008 > u2.id = 1002 > => 1002It is not appropriate to set the id values manually. Save them instead, then rails will allocate the ids.> ruby-1.9.3-head :009 > d = Decision.new > => #<Decision id: nil, user_id: nil, other details snipped> > ruby-1.9.3-head :020 > d.id = 1000 > => 1000 > ruby-1.9.3-head :010 > u1.decisions << dAgain, don''t set the ids manually, let rails do it.> => [#<Decision id: 1000, user_id: nil, other details snipped>] > ruby-1.9.3-head :011 > u2.decisions << d > => [#<Decision id: 1000, user_id: nil, other details snipped>] > ruby-1.9.3-head :016 > d > => #<Decision id: 1000, user_id: nil, other details snipped> > ruby-1.9.3-head :021 > u1.decisions > => [#<Decision id: 1000, user_id: nil, other details snipped>] > ruby-1.9.3-head :022 > u2.decisions > => [#<Decision id: 1000, user_id: nil, other details snipped>] > > How odd, user_id stays nil! Given that, I''m not sure just how Rails > "knows" that u#.decisions includes d. If anyone here has a clue, > maybe that would clear things up.Try again with letting rails manage the ids and you may get a different result. Colin -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Mon, Nov 28, 2011 at 04:12, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:> On 27 November 2011 22:34, Dave Aronson > <googlegroups2dave-BRiZGj7G2yRXqviUI+FSNg@public.gmane.org> wrote:>> ruby-1.9.3-head :005 > u1 = User.new >> => #<User id: nil, other details snipped> >> ruby-1.9.3-head :006 > u1.id = 1001 >> => 1001 >> ruby-1.9.3-head :007 > u2 = User.new >> => #<User id: nil, other details snipped> >> ruby-1.9.3-head :008 > u2.id = 1002 >> => 1002 > > It is not appropriate to set the id values manually. Save them > instead, then rails will allocate the ids.Since it was just for the purpose of a little irb experiment, I didn''t want to go to the bother of setting up a new app or jumping through the hoops to set the other fields needed to make the record saveable.> Try again with letting rails manage the ids and you may get a different result.Essentially my advice to the OP! :-) Let''s see what he says. -Dave -- LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern languages. Where: Northern Virginia, Washington DC (near Orange Line), and remote work. See: davearonson.com (main) * codosaur.us (code) * dare2xl.com (excellence). Specialization is for insects. (Heinlein) - Have Pun, Will Babble! (Aronson) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I am confused by "instead, then rails will allocate the ids." So do you mean it is improper to do this: user.Description << d If it is, can you tell me the proper way to link the association? Thanks, Kahou Dave Aronson wrote in post #1034152:> On Mon, Nov 28, 2011 at 04:12, Colin Law <clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: > >> On 27 November 2011 22:34, Dave Aronson >> <googlegroups2dave-BRiZGj7G2yRXqviUI+FSNg@public.gmane.org> wrote: > >> instead, then rails will allocate the ids. > Since it was just for the purpose of a little irb experiment, I didn''t > want to go to the bother of setting up a new app or jumping through > the hoops to set the other fields needed to make the record saveable. > >> Try again with letting rails manage the ids and you may get a different result. > > Essentially my advice to the OP! :-) Let''s see what he says. > > -Dave > > -- > LOOKING FOR WORK! What: Ruby (on/off Rails), Python, other modern > languages. > Where: Northern Virginia, Washington DC (near Orange Line), and remote > work. > See: davearonson.com (main) * codosaur.us (code) * dare2xl.com > (excellence). > Specialization is for insects. (Heinlein) - Have Pun, Will Babble! > (Aronson)-- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
kahou l. wrote in post #1033985:> car1.wheels << wheel2 > car2.wheels << wheel2 > > Note that car1 wheels STILL contains wheel2 when I reassign wheel2 to > car2. > I expect car1 doesn''t have wheel2 anymore... > > I don''t know why it doesn''t get update automatically that car1 shouldn''t > contains wheel2 anymore. Can anybody help me to solve this problem?The reason this happens is because Rails does not provide inter-model change notification. Take the line: car2.wheels << wheel2 Only car2 and wheel2 are involved in this statement. There is no change notification system in Rails to send a message to car1 informing it that anything changed. Therefore car1 only knows about the last state change where it was actually involved. If you want car1 to "wake up" and update it''s internal state then you must do that yourself by either fetching it again or forcing car1 to reload it''s state from the database: car1.reload Using reload is typically not necessary in production code because the next request usually refetches the objects involved anyway. But, it can be useful in rare situations or when using the Rails console for exactly the sort of experimenting that you''re doing now. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
kahou l. wrote in post #1034157:> I am confused by "instead, then rails will allocate the ids." > > So do you mean it is improper to do this: > > user.Description << dNo. Colin was referring to statements like in one of the replies to your question: u1.id = 1001 Don''t do this. ActiveRecord wants to manage setting the id (primary key) itself. P.S. Sorry for my continued misuse of it''s vs. its in earlier posts. That damn apostrophe keeps slipping in where it doesn''t belong. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Robert Walker wrote in post #1034162:> The reason this happens is because Rails does not provide inter-model > change notification. Take the line:Oh and BTW. If anyone is wondering why not just add a change notification system to ActiveRecord?Well, How far do you want to take that. It might be relatively straightforward if you have only a single instance of an application. However, to support scaling to multiple instances, maybe on several servers, you''d have to provide some sort of distributed change notification. Obviously, this complicates matters extensively. It''s very much easier to just go back to the database to discover changes in the underlying state. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.