Integrate versioning into AR touch method #1063
Conversation
|
Something to consider with this PR is the following lines: Currently it will attach to the |
lib/paper_trail/model_config.rb
Outdated
| @@ -196,6 +204,8 @@ def setup_callbacks_from_options(options_on = []) | |||
| options_on.each do |event| | |||
| public_send("on_#{event}") | |||
| end | |||
|
|
|||
| public_send("on_touch") | |||
There was a problem hiding this comment.
I think you can just call on_touch here, right? The public_send is not necessary.
Good thinking. I think the callback should be installed by default, but configurable via the |
|
This will need a changelog entry and probably some significant changes to documentation in comments and in the readme. |
|
I guess |
|
Okay the following items have been added to this PR:
|
| def touch_with_version(name = nil) | ||
| ::ActiveSupport::Deprecation.warn(DPR_TOUCH_WITH_VERSION, caller(1)) |
There was a problem hiding this comment.
Nice deprecation implementation
lib/paper_trail/record_trail.rb
Outdated
| @@ -563,17 +570,16 @@ def attribute_changed_in_latest_version?(attr_name) | |||
| # Rails 5.1 changed the API of `ActiveRecord::Dirty`. See | |||
| # https://github.com/airblade/paper_trail/pull/899 | |||
| # | |||
| # Event can be any of the three (create, update, destroy). | |||
| # Event can be any of the following (create, update, destroy, touch). | |||
There was a problem hiding this comment.
"touch" is not an event. There are still only three events: create, update, and destroy. touch will cause the insertion of an "update" event. See record_update.
I think this will be confusing to many people, and I'm wondering how we can document it better.
There was a problem hiding this comment.
Well should we make touch an event? I would simply add another optional argument to record_update(force:, in_after_callback:, event: "update") or add a record_touch method.
Otherwise I can simply add documentation in the readme next to the touch documentation stating that the event will be recorded as update
There was a problem hiding this comment.
should we make touch an event?
I don't know.
Reasons against: A touch is simply an update. It updates timestamps. If we had a touch event, the lifecycle would be harder to understand. Instead of eg. create-update-update-destroy, it's eg. create-update-touch-touch-update-touch-destroy. The "middle part" of the lifecycle becomes heterogeneous. This heterogeneity would be a major breaking change.
Reasons for: Maintains a one-to-one correspondence between callbacks and events, which makes callbacks easier to understand I guess. It's not a big advantage.
So I guess I'm leaning against making touch an event.
There was a problem hiding this comment.
Okay then in that case, I simply updated the readme stating the event will be saved as update
spec/models/on/update_spec.rb
Outdated
| @@ -5,9 +5,10 @@ | |||
|
|
|||
| module On | |||
| RSpec.describe Update, type: :model, versioning: true do | |||
| let(:record) { described_class.create(name: "Alice") } | |||
There was a problem hiding this comment.
Please do not use let. I believe it makes tests harder to understand, especially when it's too far away, lexically, from the test.
There was a problem hiding this comment.
Reading this from 2020, and I completely agree. It can be useful for dynamic values to DRY up tests but if it's overused, it becomes a nightmare. Additionally, the let block is only executed once it is called so that alone can be confusing and have detrimental side effects with tests.
spec/models/on/update_spec.rb
Outdated
| count = record.versions.count | ||
| expect(count).to eq(count) | ||
| end | ||
| end |
There was a problem hiding this comment.
Good test. Thanks for finding and using the existing models.
spec/models/widget_spec.rb
Outdated
| count = widget.versions.count | ||
| widget.paper_trail.without_versioning do | ||
| expect(count).to eq(count) | ||
| end |
There was a problem hiding this comment.
I don't understand the implementation of this test. It's like saying expect(7).to eq(7), right? The local variable count is unchanging, right?
|
Thanks, Weston. |
|
Is there a way to globally disable the tracking of the touch event? Or more generically, set the default /create/update/destroy/touch global 'on:' defaults ? As implemented, it breaks when using the delay_touching gem (specific case is when a delayed touch is for a record that was marked for destruction, the attempt to create the version association in record_update() in record_trail.rb throws an exception because the @record no longer is persisted (as it was deleted before the touch events are fired - touch having been delayed as the function of the delay_touching gem). Given this was not the default behavior before and the alternative is updating potentially hundreds of models (we have a pretty large app) to disable on: :touch, I'd much rather have a PaperTrail.config.xxxx setting once. We upgraded from 7.x to 10.x and had this break (it worked before, likely because it was before touch versioning was done) |
|
.... of course it does, you wrote it. |
* integrate versioning into AR touch method * add touch to list of :on events, deprecate touch_with_version * integrate versioning into AR touch method
Related to Issue 1061