On 7/30/06, Jeremy Kemper <[EMAIL PROTECTED]> wrote:
On Jul 28, 2006, at 8:29 PM, Daniel N wrote:
> Just a thought tho. By raising an exception, this would put
> destroy into a different category, this should perhaps be destroy!
> to fit with the other methods that raise errors.
Good call. Really, destroy_with_callbacks should rollback the
transaction when a before_destroy callback is false rather than
returning false and committing. Then the implementation simplifies
back to
case reflection.options[:dependent]
when :restrict
class_eval "before_destroy { |model| model.#
{reflection.name}.blank? }"
jeremy
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
This is very similar to the solution that I came up with initially. Thinking that a return of false would roll back the destroy.
case reflection.options[:dependent]
when :restrict
module_eval "before_destroy '#{reflection.name}.count == 0'"
As I understand it class_eval is an alias for module_eval so I think that the code you suggested and what I had were basically doing the same thing.
This approach however didn't work in the tests. When I had a has_many declared with :dependent => :destroy before the has_many with :restrict the first associations objects were destroyed before the destroy chain was halted. It didn't seem to roll back in the tests
The test that I had was
num_association_1 = @obj.association_1.count
num_associaton_2 = @obj.association_2.count
@obj.destroy
assert [EMAIL PROTECTED]
assert @obj.association_1.count == num_association_1 # <= Test fails here
assert @obj.association_2.count == num_association_2
The @obj was not frozen but association_1 no longer had the objects in it.
I really don't know how to proceed from here. It surely isnt' as hard as I've made it, I'm positive I'm doing something not quite right. I just don't understand why the destroy isn't rolled right back to the start.
I then took another approach of including a class variable and adding any restricted associations to it. Then on each call to before_destroy, I went through each restriced association and checked returning false if a restricted association was found. Trying a little overkill really. This broke a lot of existing tests in AR.
This is a lot harder than I thought it was going to be. Thanx so much for your patience with this and for your help.
Cheers
Daniel
_______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
