-
-
Notifications
You must be signed in to change notification settings - Fork 725
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
2700 improve product refresh scheduling #2701
2700 improve product refresh scheduling #2701
Conversation
j.class == RefreshProductsCacheJob && | ||
j.distributor_id == distributor.id && | ||
j.order_cycle_id == order_cycle.id | ||
}.any? |
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.
what is the exact difference? although very slow, weren't we checking the same? no ho entenc
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.
Yes, the logic is the same. We check for an identical job.
BUT: The previous implementation needed to call payload_object
on each job. That call fails if the object can't be deserialised properly. That happens when the payload object is a user and that user doesn't exist any more. In that case map(&:payload_object)
raised Delayed::DeserializationError
caused by ActiveRecord::RecordNotFound
. Instead of rescueing from that error in a separate each block, I simplified the implementation to just check for the serialised content in the db column handler
. That avoids the error and is more efficient.
|
||
def self.enqueue_job(job) | ||
Delayed::Job.enqueue job, priority: 10 | ||
class << self |
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.
what happened here?
I just spent half an hour reading about eigenclasses... my head hurts :-)
In this particular case, is this a convention (use class << self instead of self. ) or is there any change in logic with 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.
I'd like to check what the Ruby Style guide says about it and I'd stick to the community's default. Also, private
doesn't work for class methods AFAIK, so I'm not sure here if these methods get hid.
You met the deepest part of Ruby, congrats @luisramos0
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.
hmm.. I read a bit more about this and actually, this is exactly how you create private class methods :-)
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.
I know! I was a bit reluctant to use class << self
here, but I followed rubocop and found that it is the widely accepted way to declare private class methods. I should have tackled one rubocop violation at a time to explain it better. Sorry.
The alternative is to declare it separately:
private_class_method :refresh_job
private_class_method :pending_job?
private_class_method :enqueue_job
That is more repetitive, but you definitely know what it's doing. Should I change it?
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.
👍
private_class_method is much easier to understand :-)
If it's also correct I'd use it.
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.
Okay, please see my additional commit. If you approve, I will squash it with the previous commit.
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.
yes, imo, much better.
Testing notes I followed the testing steps and was able to create and edit an OC just fine. https://docs.google.com/document/d/1yU8Zmi10aJcJzb0W8tOGV1GufGgt1uUKEiTY146hElE/edit# |
What? Why?
Closes #2700.
When broken delayed jobs are in the database, product cache refreshment fails as described in the issue.
What should we test?
[email protected]
Release notes
Fixed order cycle creation which failed when invalid user accounts were deleted.
Changelog Category: Fixed