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

No way to programatically restart a job? #81

Closed
hubertlepicki opened this issue Jun 15, 2019 · 1 comment
Closed

No way to programatically restart a job? #81

hubertlepicki opened this issue Jun 15, 2019 · 1 comment

Comments

@hubertlepicki
Copy link

So I am using Honeydew + Ecto, and I can't find a way to restart / re-run a job.

In my case, I have a job that I want to be run every time a record in my database has been created, and this works great.

However, I would like to also schedule a job once the record has been updated.

If I understand correctly there is currently no way to do it short of manually setting record's honeydew fields to default values, as they were when record been created.

But this puts me at risk at race condition if the record is being updated while the initlal job is running, or when multiple updates happen in short periods of time.

What is the correct way of handling the situation of running a job on record updates?

My current thinking is we create associated record that represents the record update, and corresponding job. So, if I have Photo, and I want to run ClassifyPhoto job after each update, I insert for each photo update a record, say PhotoUpdated, with a timestamp and honeydew fields, and hook up ClasifyPhoto job to this PhotoUpdated - and not Photo schema.

Is my thinking correct or am I missing some smart funcionality Honeydew provides to do it?

@koudelka
Copy link
Owner

koudelka commented Jun 17, 2019

Hey there, this isn't a use case that the Ecto queue was designed to accommodate. It's really meant for simple one-row-one-job scenarios. You're certainly right about resetting the fields to their default values, that'd be bad.

Your solution would work just fine, but maybe your situation would be a better fit for a different job queue, so you don't have to resort to hacks?

There's a little list here:

https://elixirforum.com/t/background-job-queues-when-to-use-when-not-to-use-which-one-to-use/20436

as well as

https://elixirforum.com/t/oban-reliable-and-observable-job-processing/22449

A lot of the more featureful Elixir job queues require postgres, which is sort of a bummer, though. The use case that I have doesn't tolerate SPOF nodes.

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

2 participants