This project is archived and is in readonly mode.
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 December 12th, 2010 @ 11:41 AM
After digging a while I found that everything works fine when
has_oneis placed belowbefore_destroymethod.
This is caused by defining callback method:has_one_dependent_nullify_for_addressby methodhas_one.
See code here:
Defining method executed by before_destroyOrder of methods passed to
before_destroyis 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 December 16th, 2010 @ 09:41 AM
I added failing test.
You can check, that test will pass if line:
will be moved to top of file.before_destroy { |company| company.account && company.account.set_dependent_firm_name }
Reason of this is as described in previous comment. -
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 March 17th, 2011 @ 12:00 AM
- State changed from “open” to “stale”
-
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-bugI'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>
Wojciech Wnętrzak