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

Resque::Helpers will be gone with no replacement in Resque 2.0.0. #32

Open
kforsman opened this issue Sep 23, 2013 · 16 comments
Open

Resque::Helpers will be gone with no replacement in Resque 2.0.0. #32

kforsman opened this issue Sep 23, 2013 · 16 comments

Comments

@kforsman
Copy link

Hi there, thanks for a great gem. I have started to see this warning in the logs (Resque::Helpers will be gone with no replacement in Resque 2.0.0.), looks like it stems from resque-loner. Any plans to make it compatible with Resque 2.0?

@kaluznyo
Copy link

kaluznyo commented Oct 7, 2013

+1

5 similar comments
@sahin
Copy link

sahin commented Oct 11, 2013

+1

@gthiruva
Copy link

gthiruva commented Nov 7, 2013

+1

@hlascelles
Copy link

+1

@apsoto
Copy link

apsoto commented Nov 25, 2013

+1

@matteomelani
Copy link

+1

@teeparham
Copy link

I began to fix this at https://github.com/teeparham/resque-loner & ended up re-writing it as a separate gem called resque_solo. The plugin's job name is still Resque::Plugins::UniqueJob so all you need to do to swap back & forth is change the gem. It removes the Resque::Helpers warnings for resque 1.25.

https://github.com/neighborland/resque_solo

@apsoto
Copy link

apsoto commented Dec 18, 2013

When you say rewrite does that mean it's not a simple fork plus patch? Loner has been stable for so long 'rewrite' concerns me.

@teeparham
Copy link

@apsoto Re: resque_solo: The tests are basically the same. I used fakeredis instead of an actual redis server in test. I re-structured the internal classes. I started with a blank project & copied many of the tests and much of the code. We're running it in production, if that helps.

@pangkalizer
Copy link

+1

@rwojsznis
Copy link

@teeparham - neat, thanks 👍 for effort, will give it a try

@faheemmughal
Copy link

+1

1 similar comment
@klippx
Copy link

klippx commented Aug 4, 2014

+1

@tkalimov
Copy link

tkalimov commented Oct 7, 2014

@teeparham I love the addition of the lock_after_execution_period -- exactly what I was looking for. Thank you!

@nickmalcolm
Copy link

+1

1 similar comment
@idlecool
Copy link

+1

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

No branches or pull requests