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@googlegroups.com.
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.

Search Discussions

  • Colin Law at Nov 27, 2011 at 9:48 pm

    On 27 November 2011 21:27, kahou l. 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@googlegroups.com.
    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.
  • Kahou l. at Nov 27, 2011 at 9:56 pm
    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@googlegroups.com.
    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.
  • Colin Law at Nov 27, 2011 at 10:12 pm

    On 27 November 2011 21:56, kahou l. 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@googlegroups.com.
    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.


    --
    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@googlegroups.com.
    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.
  • Dave Aronson at Nov 27, 2011 at 10:35 pm

    On Sun, Nov 27, 2011 at 16:27, kahou l. 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@googlegroups.com.
    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.
  • Colin Law at Nov 28, 2011 at 9:13 am

    On 27 November 2011 22:34, Dave Aronson wrote:
    On Sun, Nov 27, 2011 at 16:27, kahou l. 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
    It 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 << d
    Again, 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@googlegroups.com.
    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.
  • Dave Aronson at Nov 28, 2011 at 5:57 pm

    On Mon, Nov 28, 2011 at 04:12, Colin Law wrote:

    On 27 November 2011 22:34, Dave Aronson
    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@googlegroups.com.
    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.
  • Kahou l. at Nov 28, 2011 at 6:59 pm
    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 wrote:

    On 27 November 2011 22:34, Dave Aronson
    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@googlegroups.com.
    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.
  • Robert Walker at Nov 28, 2011 at 7:37 pm

    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 << d
    No. 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@googlegroups.com.
    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.
  • Robert Walker at Nov 28, 2011 at 7:32 pm

    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@googlegroups.com.
    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.
  • Robert Walker at Nov 28, 2011 at 7:48 pm

    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@googlegroups.com.
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprubyonrails-talk @
categoriesrubyonrails
postedNov 27, '11 at 9:28p
activeNov 28, '11 at 7:48p
posts11
users3
websiterubyonrails.org
irc#RubyOnRails

People

Translate

site design / logo © 2021 Grokbase