Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip yielding when no block provided #213

Closed
wants to merge 3 commits into from
Closed

Skip yielding when no block provided #213

wants to merge 3 commits into from

Conversation

mikwat
Copy link
Collaborator

@mikwat mikwat commented Dec 21, 2017

Normally track_history_for_action is always called with a block via around_create/update/destroy, but I've found in my own code base that there are times when it's desirable to call this method directly without a block.

Regardless, this change seems like good hygiene with little downside. If a block isn't provided, then there's no need to rescue and rollback the new history track.

@mikwat mikwat requested a review from dblock December 21, 2017 23:22
@coveralls
Copy link

coveralls commented Dec 21, 2017

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 500e795 on skip-yield into e5a6f77 on master.

@coveralls
Copy link

coveralls commented Dec 21, 2017

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 17d3ba2 on skip-yield into e5a6f77 on master.

2 similar comments
@coveralls
Copy link

coveralls commented Dec 21, 2017

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 17d3ba2 on skip-yield into e5a6f77 on master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 17d3ba2 on skip-yield into e5a6f77 on master.

@@ -282,6 +282,8 @@ def track_history_for_action(action)

clear_trackable_memoization

return unless block
Copy link
Collaborator

@dblock dblock Dec 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ruby way is to do unless block_given? (which I believe is much faster) and to mark the block above as _block.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good feedback, thanks!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out, with block_given? there's no need for a &block param!

@@ -621,6 +621,19 @@ def self.name
end
end

describe '#track_history_for_action' do
before(:all) { MyModel.track_history }
let!(:m) { MyModel.create!(foo: 'bar') }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't need a ! here, nitpick.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@coveralls
Copy link

coveralls commented Dec 22, 2017

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 6f49ae1 on skip-yield into e5a6f77 on master.

3 similar comments
@coveralls
Copy link

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 6f49ae1 on skip-yield into e5a6f77 on master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 6f49ae1 on skip-yield into e5a6f77 on master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.0004%) to 99.803% when pulling 6f49ae1 on skip-yield into e5a6f77 on master.

expect { m.send(:track_history_for_action, :update) }.not_to raise_error
end
end

Copy link
Collaborator

@dblock dblock Dec 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should rewrite the tests at a higher level, so not calling track_history_for_action via a send, but wherever this is actually used, because that is an internal function and we want to make sure the code works at the public interface level.

@@ -282,6 +282,8 @@ def track_history_for_action(action)

clear_trackable_memoization

return unless block_given?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do add &_block as a parameter in the function definition to make it clear that this function allows for a block.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok.

@@ -5,6 +5,7 @@
* [#205](https://github.com/mongoid/mongoid-history/pull/205): Allow modifier field to be optional - [@yads](https://github.com/yads).
* [#211](https://github.com/mongoid/mongoid-history/pull/211): Enable tracking create/destroy by default - [@jagdeepsingh](https://github.com/jagdeepsingh).
* [#212](https://github.com/mongoid/mongoid-history/pull/212): `track_history` method support for `:if` and `:unless` options - [@jagdeepsingh](https://github.com/jagdeepsingh).
* [#213](https://github.com/mongoid/mongoid-history/pull/213): Skip yielding when no block provided - [@mikwat](https://github.com/mikwat).
Copy link
Collaborator

@dblock dblock Dec 22, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unclear what is no longer yielding, so should say Do not yield on ... when no block is provided or something like that.

@dblock
Copy link
Collaborator

dblock commented Dec 22, 2017

Since this is an interface change I would expect something to be updated in README, too.

@mikwat
Copy link
Collaborator Author

mikwat commented Dec 22, 2017

Thanks for the feedback @dblock I'm realizing the root problem appears to be that has_and_belongs_to_many relations may not be properly tracked. I'm going to close this PR and create a spec to explain what I'm seeing.

@mikwat mikwat closed this Dec 22, 2017
@mikwat mikwat deleted the skip-yield branch December 22, 2017 23:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants