Allow jobs that are immediately ready-to-run to skip the promote cycle.

[vsivsi]

See: #15 (comment)

[vsivsi]

One slightly tricky thing here is that some of the methods impacted can work on multiple jobs simultaneously. So some jobs may be ready and others not...

• .save() -- Only one job at a time
• .rerun() -- Only one job at a time
• .resume() -- Multiple jobs
• .restart() -- Multiple jobs

[mitar]

Maybe you could add .save().promote()? But it would be better that this is called automatically.

[mitar]

Hm, but pool() is quite efficient, not sure if this is a problem on a busy server? Only one query more?

[vsivsi]

Try out the instant_ready branch and let me know what you think. Should be completely automatic.

[mitar]

OK, but it is doing one more query? I don't think this is a too big issue.

[vsivsi]

Yes, it's doing another update, but restricted to the id(s) involved in the invoking method, which should make it much faster than the full query used when promote polls.

[mitar]

I like it. Thanks!

[mitar]

This is quick now! Especially with my observe-based worker. :-)

Now I just have to see what happens when there are dependencies between documents. Do I have to wait for promote to discover that, or does it set ready state automatically after done to all dependent jobs.

[vsivsi]

Dependencies are resolved by job.done(), which doesn't cause the ready state of any affected jobs to be evaluated. So, you are correct, they will wait until the next promote cycle.

[mitar]

But this would be easy to add, no? Using the same technique, calling pool on all dependent jobs? Maybe this could be an option to done(), to make it do this two additional queries (one to find dependent jobs, one to update them)?

[vsivsi]

This has been committed on the dev branch

[vsivsi]

merged into master