Hi, On AWDWR page 332 there is this example class Order < ActiveRecord::Base has_one :invoice end order = Order.new(... attributes ...) invoice = Invoice.new(... attributes ...) order.invoice = invoice And then the explanation: If there is already an existing child object when you assign a new object to a has_one association, that existing object will be updated to remove its foreign key association with the parent row(the foreign key will be set to null) I find that however that if: 1) I change has_one :invoice :dependent => :destroy then the existing object is actually DELETED rather than just FK being set to null 2) However for the same has_one :invoice :dependent => :destroy if I use build_invoice instead of assignment i.e. order.build_invoice instead of order.invoice = invoice then the Existing object''s FK is NULLED out and NOT deleted. I''m just trying to figure if: a) Both observations above are correct b) Why the difference in behavior - i.e. assignment DELETEs the existing record, whereas build_association NULLs the FK --~--~---------~--~----~------------~-------~--~----~ 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Hi, On AWDWR page 332 there is this example class Order < ActiveRecord::Base has_one :invoice end order = Order.new(... attributes ...) invoice = Invoice.new(... attributes ...) order.invoice = invoice And then the explanation: If there is already an existing child object when you assign a new object to a has_one association, that existing object will be updated to remove its foreign key association with the parent row(the foreign key will be set to null) I find that however that if: 1) I change has_one :invoice :dependent => :destroy then the existing object is actually DELETED rather than just FK being set to null 2) However for the same has_one :invoice :dependent => :destroy if I use build_invoice instead of assignment i.e. order.build_invoice instead of order.invoice = invoice then the Existing object''s FK is NULLED out and NOT deleted. I''m just trying to figure if: a) Both observations above are correct b) Why the difference in behavior - i.e. assignment DELETEs the existing record, whereas build_association NULLs the FK -- 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
augustlilleaas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
2007-Jan-22 23:01 UTC
Re: has_one behavior - AWDWR page 332
1) :dependend => :destroy is supposed to delete it. If you don''t have that defined, it''ll sett the association to null On Jan 22, 6:04 pm, Karthik Nar <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> Hi, > > On AWDWR page 332 there is this example > > class Order < ActiveRecord::Base > has_one :invoice > end > > order = Order.new(... attributes ...) > invoice = Invoice.new(... attributes ...) > order.invoice = invoice > > And then the explanation: If there is already an existing child object > when you assign a new object to a has_one association, that existing > object will be updated to remove its foreign key association with the > parent row(the foreign key will be set to null) > > I find that however that if: > > 1) I change has_one :invoice :dependent => :destroy then the existing > object is actually DELETED rather than just FK being set to null > > 2) However for the same has_one :invoice :dependent => :destroy if I > use build_invoice instead of assignment > i.e. order.build_invoice instead of order.invoice = invoice > then the Existing object''s FK is NULLED out and NOT deleted. > > I''m just trying to figure if: > > a) Both observations above are correct > b) Why the difference in behavior - i.e. assignment DELETEs the > existing record, whereas build_association NULLs the FK > > -- > Posted viahttp://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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 1) :dependend => :destroy is supposed to delete it. If you don''t have > that defined, it''ll sett the association to nullHi, you''re right however :dependent => :destroy as per the documentation, is supposed to work when the parent is deleted. however, in the examples above, it seems to take effect even for "normal" association cases. And in that too, there is a discrepancy, build_association NULLs the FK, but assignment DELETEs the child record! puzzling ... -- 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-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---