-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Fixes for discard 1.1.0 #3202
Fixes for discard 1.1.0 #3202
Conversation
We already had this but with the last version of discard the validation is no more performing. I think it's something related to this commit jhawthorn/discard@dfdd984 which is included in the last release. Before the release, calling discarded? on the line: validate :validate_no_amount_used, if: :discarded? was returning true, even if the record change wasn't yet persisted. We don't need that line anymore since now records can't be discarded without passing the after_discard validation so we should not have any of those. Anyway, even if that happens we don't want to block other updates on those records.
This is needed to avoid discard to set deleted_at anyway. Now that we are not running this method as a validation anymore we need to stop the callback chain by throwing abort, see: https://api.rubyonrails.org/classes/ActiveModel/Callbacks.html
9538146
to
892e5dc
Compare
@jarednorman do you think we need to update the discard dependency along with this change? I'm not sure the old discard version is compatible with this new code. Let me know! |
In reviewing the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM assuming it is backwards compatible. If not we'll need to update the discard version in the gemspec
I've just run specs with discard Investigation that leads me to open jhawthorn/discard/issues/51I've also tried to run `master` specs with discard `1.0.0` and they pass. Next attempt done is using previous specs and discard `1.1.0`, which had the failure that originated this PR. I changed in discard locally: run_callbacks(:discard) do
update_attribute(self.class.discard_column, Time.current)
end to: with_transaction_returning_status do
run_callbacks(:discard) do
self[self.class.discard_column] = Time.current
save
end
end and specs pass, so I assumed the problem is here. I then changed that block into: run_callbacks(:discard) do
self[self.class.discard_column] = Time.current
save
end removing From with_transaction_returning_status API reference, it:
I think that removing this method somehow changes the state the record is when it's time to execute validations, but I'm not sure if it's an issue worth spending too much time on so I've opened this PR on discard. I'd say to wait to see if we receive some feedback on that issue otherwise, we can safely merge this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that I understand the change that caused this to break, I'm in favour of this fix. Thanks for addressing this! 🤘🏻
Description
This PR fixes a bug with the last version of discard. I think the bug was more related to how we were using discard than to the discard update itself.
TLDR;
discarded?
was returning true, even when the record updated todeleted_at
wasn't yet persisted. This behavior seems to be changed (probably correctly?) so this validationwas never performed on the first
discard
call, which is exactly what we need.This PR changes that way to validate the record into a
before_discard
callback (similar to what we have with theafter_destroy
), throwingabort
to interrupt the callback chain.Asking for a @jarednorman review as well, since he's the new discard maintainer. 🎉
Checklist: