Rails 5.1 saved_changes is broken when updating parent_id on existing model

[schovi]

Having simple model

class Category < ApplicationModel
  has_closure_tree order: :position
  before_save :show_changes
  after_save :show_saved_changes

  def show_changes
    p "changes #{changes}"
  end

  def show_saved_changes
    p "saved_changes #{saved_changes}"
  end
end

When updating position attribute or other model attributes it behave as expected. But when I change parent_id it will print

changes {"parent_id": [1, 2]}
saved_changes {}

The problem seems to be in closure tree after_save callback in if branch for not a new record.

if public_send(changes_method)[_ct.parent_column_name] && !@was_new_record
  # Resetting the ancestral collections addresses
  # https://github.com/mceachen/closure_tree/issues/68
  ancestor_hierarchies.reload
  self_and_ancestors.reload
end

which will obviously reload and clear model.

Quick solution is to put my callbacks before initializing closure tree in model

class Category < ApplicationModel
  before_save :show_changes
  after_save :show_saved_changes

  has_closure_tree order: :position
end

But it is not that pretty and you can run to other issues.

PS: think if there is more things which can break due to closure tree saving

[schovi]

Naive fix #272

[fmluizao]

This is generating a lot of warnings with Rails 5.1 too:

DEPRECATION WARNING: The behavior of `changes` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_changes` instead.
DEPRECATION WARNING: The behavior of `changed` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_changes.keys` instead.
DEPRECATION WARNING: The behavior of `attribute_change` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute` instead.
DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead.

However, I did not experience any problems so far.

[schovi]

These warnings are with or without my patch. See #269

When you have not experienced any problem, have you tried exactly what I wrote in the description?
The problem is obviously visible from source code, where closure tree reloads model which reset it to initial state.

I just need to validate my fix if there is something more which is needed to persist. And add test ofc :D

[mceachen]

I'd love to merge that PR, but the tests need to pass. I don't have time to help with that right now, I'm afraid.

[Exelord]

Hey, any progress on this?

[mceachen]

@Exelord feel free to fix the PR!

[schovi]

If anybody can help with tests it would be awesome.

[n-rodriguez]

@schovi this should have been fixed : https://github.com/ClosureTree/closure_tree/blob/master/lib/closure_tree/hierarchy_maintenance.rb#L38
Can you please test with master branch?

[schovi]

@n-rodriguez seems fine 👍

[TBadyl]

Hey.

I just stumbled into the same issue. In the after_save callbacks the saved_changes hash is emptified by closure_tree callbacks and I have no way to determine what attributes has changed.

Any plans to address this issue?