This project is archived and is in readonly mode.

#6150 open
Wojciech Wnętrzak

Has one association nullifies object to early

Reported by Wojciech Wnętrzak | December 11th, 2010 @ 02:47 PM

The best way to show the problem will be by code:

class User < ActiveRecord::Base
  has_one :address, :dependent => :nullify
  before_destroy :address_do_something
  delegate :do_something, :to => :address, :prefix => true
end
class Address < ActiveRecord::Base
  belongs_to :user
  def do_something
    # do something with user which shouldn't be nil
    user.inspect
  end
end

Problem is when method do_something is called by User before_destroy callback. When option dependent is specified to nullify, associated user is nil (this is happening before destroy).
Shouldn't this associated object be set to nil after destroy?

You can see and check that bug in sample app:
https://github.com/morgoth/nullify-bug

Comments and changes to this ticket

  • Wojciech Wnętrzak

    Wojciech Wnętrzak December 12th, 2010 @ 11:41 AM

    After digging a while I found that everything works fine when has_one is placed below before_destroy method.
    This is caused by defining callback method :has_one_dependent_nullify_for_address by method has_one.
    See code here:
    Defining method executed by before_destroy

    Order of methods passed to before_destroy is important.
    Maybe methods generated by rails should be somehow placed at the end of this chain?

    And another question:
    Is there a proper order of using methods like: has_one, validates, before_destroy, etc. in ruby file, that will avoid problems like this one?

  • Wojciech Wnętrzak

    Wojciech Wnętrzak December 16th, 2010 @ 09:41 AM

    I added failing test.
    You can check, that test will pass if line:

    before_destroy { |company| company.account &amp;&amp; company.account.set_dependent_firm_name }
    
    will be moved to top of file.
    Reason of this is as described in previous comment.
  • rails

    rails March 17th, 2011 @ 12:00 AM

    • State changed from “new” to “open”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • rails

    rails March 17th, 2011 @ 12:00 AM

    • State changed from “open” to “stale”
  • Wojciech Wnętrzak

    Wojciech Wnętrzak March 18th, 2011 @ 04:35 PM

    • State changed from “stale” to “open”

    This problem still appears on rails master.
    I updated sample failing app to rails master: https://github.com/morgoth/nullify-bug

    I'm also submitting rebased patch with failing test.

    [state:open]

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

People watching this ticket

Attachments

Pages