Deprecation Warning: The behavior of attribute_changed? will be changing.

[Flauschbaellchen]

I'm using self.subtree in an after_save callback.

While using Rails 5.1.4 I'm getting this warning:

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.

My use-case is to track the latest reply-timestamp within a tree of emails:

class Letter < ApplicationRecord
  has_ancestry orphan_strategy: :adopt
  after_save :touch_root_letter
  def update_last_reply_at!
    self.update_columns(last_reply_at: self.subtree.where(draft: false).pluck(:created_at).max || self.created_at)
  end
  def touch_root_letter
    self.root.update_last_reply_at!
  end
end

[Flauschbaellchen]

As soon as I submitted this issue I re-checked the PRs and found #370 which I missed somehow on my first time. Sorry.

[kbrock]

Hello @Flauschbaellchen

Please let me know if I understand this correctly:

If the tree changes, then you want to update the subtree based upon the new tree - right?
So it looks like it will work correctly with the newly defined rails behavior.

I think the issue is: There is a deprecation message and we want to double check things and make that deprecation go away.

Sound right to you?

[Flauschbaellchen]

Hi @kbrock,

I wanted to update the root-node within a tree if the node itself or some other node within this subtree has been changed.
This was an ugly workaround to be able to list all root-nodes sorted by their last changes like topics in an email-client using an index on last_reply_at without doing a more complex query.

Eventually when using #root or #subtree the method #attribute_changed? has been called.
And because I run this snippet within an after_save-callback the deprecation warning has been thrown.

This is not a bug because everything worked great nevertheless.. just a heads up for the deprecation warning ;)

Just ask if you need help to run some tests against master.
I've changed my app and seperated those letter-root-nodes into topics but I can jump to an older commit and rerun my tests to check if those warnings have been fixed.

[kbrock]

@Flauschbaellchen I put together #387. I thought I had resolved all these issues in the last release, but a few more was sneaking through.

If you get the chance, could you let me know if your workflow still works with #387 (or maybe it has merged by the time you read this)

Thanks so much for bringing this up to my attention.

[causztic]

Hello,

I have this following line of code:
after_save :update_full_path, if: -> { saved_change_to_name? }

  def update_full_path
    full_path = if root?
                  name
                else
                  (path - [root]).map(&:name).join "/"
                end

    update_column(:full_path, full_path)
    touch
    children.each(&:update_full_path)
  end

I am still having the deprecation messages of:

DEPRECATION WARNING: The behavior of `attribute_was` 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 `attribute_before_last_save` instead. (called from update_full_path at /.../models/tree_category.rb:54)
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. (called from update_full_path at /.../models/tree_category.rb:54)

Any ideas?

[kbrock]

hello @causztic

Here are a few ideas regarding your question:

1. I put in a test example for the test path. it seems a little more efficient and I'm pretty sure it does not complain: testing hooks and ancestry value #404
2. Do you have a link to the code. What exactly is at tree_category.rb:54?
3. Have you run bundle update?
4. What version of rails and ancestry? (is it covered by .travis.yml?)

[causztic]

Hello!
The bundle has the version already at 3.0.2, which bundle update did not pick up as this particular fix is not in a newer version release. I changed it to specifically target the master branch and it's working okay now. Sorry about that!

[kbrock]

@causztic thanks - I'll release shortly