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

Job tracking improvements #210

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Aeon
Copy link

@Aeon Aeon commented Sep 6, 2014

  • add helper methods to support fetching started/updated timestamps
  • do not discard started timestamp on update
  • simplify job id mapping
  • sanity check update() to accept valid statuses only

all tests still pass 😣

@@ -45,6 +45,9 @@ class Resque_Redis
'setex',
'get',
'getset',
'hset',
'hmset',
'hget',
'setnx',
Copy link
Author

Choose a reason for hiding this comment

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

should we add the rest of them?

HDEL
HEXISTS
HGETALL
HINCRBY
HINCRBYFLOAT
HKEYS
HLEN
HMGET
HSCAN
HSETNX
HVALS

@danhunsaker
Copy link
Contributor

This completely breaks interoperability with other Resque implementations, and thus will be rejected.

@Aeon Aeon force-pushed the job-tracking-improvements branch from d93a3fb to c1f91d6 Compare September 10, 2014 23:13
@Aeon
Copy link
Author

Aeon commented Sep 10, 2014

@danhunsaker ahh... good point, I thought this type of job tracking was php-resque specific. In that case, I have reverted the hash changes, and left only the bugfix and enhancements in the pull request. Please review and let me know if there is any other feedback!

Thank you!

$statusPacket = array(
'status' => $status,
'updated' => time(),
'started' => $this->fetch('started')
Copy link
Author

Choose a reason for hiding this comment

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

we were discarding started on update previously.

@Aeon Aeon force-pushed the job-tracking-improvements branch from c1f91d6 to 1033d33 Compare September 10, 2014 23:25
@danhunsaker
Copy link
Contributor

Looks good overall from here. We'll have to keep in mind that the sanity check is there in case we, the Ruby implementation, or a plugin decide to add status values to the allowed list, but that's a relatively minor concern, I think.

@Aeon
Copy link
Author

Aeon commented Sep 19, 2014

I'm not sure why it says Travis build failed, can I trigger another build somehow? I am pretty sure it's safe to merge :)

@danhunsaker
Copy link
Contributor

Check what test(s) failed and make sure it's not your PR that breaks it/them. It might just be a bad test that wasn't updated with a different change, or a problem with Travis itself.

@Aeon
Copy link
Author

Aeon commented Sep 20, 2014

No tests are failing for me. As far as I can tell, the travis build timed out trying to install phpunit? https://travis-ci.org/chrisboulton/php-resque/jobs/34966352

I don't think I have access to re-run the build without pushing a new commit?

@danhunsaker
Copy link
Contributor

Yes, but since @chrisboulton is the only one with repo write access, only he can see the rebuild button and trigger the rebuild process. I doubt there would be an issue, though, since every other test config passed, and the failure on the only one that failed was due to a Composer issue (frighteningly common in automated environments), so it's probably safe to merge anyway.

@wedy
Copy link
Contributor

wedy commented Sep 20, 2014

@Aeon, try amend and push --force it again, it will trigger travis again

@chrisboulton
Copy link
Owner

@danhunsaker, @Aeon - what was the conclusion on this change breaking interop? I had a quick look through, and nothing immediately stands out?

@Aeon
Copy link
Author

Aeon commented Nov 21, 2016

@chrisboulton I rolled back the interop breaking change, so this should be entirely safe at this point

On Nov 21, 2016, at 1:50 PM, Chris Boulton notifications@github.com wrote:

@danhunsaker, @Aeon - what was the conclusion on this change breaking interop? I had a quick look through, and nothing immediately stands out?


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

/**
* generate job id consistently
*/
private static function generateId($id) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you please use common style? I mean put opening braces for methods to the next line

Copy link
Contributor

@sergeyklay sergeyklay Nov 22, 2016

Choose a reason for hiding this comment

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

Using private visibility means we can't just inherit the class because public methods call private methods. How about protected visibility?

Copy link
Author

Choose a reason for hiding this comment

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

Done and done. Though, I see a number of other classes in the project that have functions with inconsistent opening braces, so didn't realize there was a consistent style to follow.

*
* @return mixed False if the status is not being monitored, otherwise the status packet array or the individual field
*/
private function fetch($field = false)
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you please put protected/private at the end of class?

Copy link
Author

Choose a reason for hiding this comment

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

Done

 - add helper methods to support fetching started/updated timestamps
 - do not discard `started` timestamp on update
 - simplify job id mapping
 - sanity check `update()` to accept valid statuses only
@Aeon Aeon force-pushed the job-tracking-improvements branch from b22a5e3 to 16218a1 Compare November 29, 2016 02:02
@Aeon
Copy link
Author

Aeon commented Feb 24, 2017

Let me know if there's any other concerns with this pull request :)

@danhunsaker
Copy link
Contributor

@chrisboulton - In its first incarnation, it changed the way jobs are stored in Redis, but once that was pointed out, those changes were removed. I looked through the rest and it looks good, now.

@Aeon - Nothing I'm aware of that should block this change being merged. Just waiting for Chris to have the time to review and merge.

👍

danhunsaker added a commit to resque/php-resque that referenced this pull request Dec 11, 2018
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.

5 participants