Batches and trackable jobs

[rustworthy]

As per issue

• Add support for batch jobs
• Add tracker responsible for tracking jobs and batch statuses;

---

This change is 

[codecov]

Codecov Report

Attention: 187 lines in your changes are missing coverage. Please review.

Comparison is base (0bd2ab0) 74.9% compared to head (62ec997) 68.4%.

Additional details and impacted files

Files	Coverage Δ
src/consumer/mod.rs	69.6% <100.0%> (+0.5%)	⬆️
src/proto/single/ent/mod.rs	100.0% <100.0%> (ø)
src/proto/single/utils.rs	100.0% <100.0%> (ø)
src/proto/single/mod.rs	93.9% <90.0%> (-0.5%)	⬇️
src/proto/single/ent/utils.rs	0.0% <0.0%> (ø)
src/producer/mod.rs	65.0% <26.6%> (-11.8%)	⬇️
src/proto/single/ent/cmd.rs	0.0% <0.0%> (ø)
src/proto/single/resp.rs	84.7% <0.0%> (-4.9%)	⬇️
src/proto/batch/cmd.rs	0.0% <0.0%> (ø)
src/proto/mod.rs	70.3% <43.5%> (-9.2%)	⬇️
... and 2 more

[jonhoo]

Awesome stuff, thank you! Left a few notes, but none that I think are particularly onerous 🎉

[jonhoo]

Basically just nits left!

One thought I have: is there even a reason to have Producer and Client be different types? Like, could we literally change Producer to

pub type Producer<S> = Client<S>;

?

[rustworthy]

Basically just nits left!

One thought I have: is there even a reason to have Producer and Client be different types? Like, could we literally change Producer to

pub type Producer<S> = Client<S>;

?

Hmm we could not without exposing methods enqueue , info, queue_pause, queue_resume, start_batch, open_batch and commit_batch on the Client.

[jonhoo]

Going to land this as that discussion is a bit separate, and would probably be breaking.

[jonhoo]

Hmm we could not without exposing methods enqueue , info, queue_pause, queue_resume, start_batch, open_batch and commit_batch on the Client.

Right, but I guess my argument is that there isn't semantically really a difference between a Client and a Producer (I think?).

[jonhoo]

Looks like #54 caused some conflicts with this one — I've resolved them and pushed directly to your branch to merge 👍

[jonhoo]

Worth highlighting the change I made in 6c98127 too. I also decided to do that because it meant my editor kept changing the uses, and then the job requires that I run a manual command to change them back, which became tedious pretty quickly 😅

[jonhoo]

Released in 0.12.5 🎉

[rustworthy]

Hmm we could not without exposing methods enqueue , info, queue_pause, queue_resume, start_batch, open_batch and commit_batch on the Client.

Right, but I guess my argument is that there isn't semantically really a difference between a Client and a Producer (I think?).

I guess semantically both Producer and Consumer are Clients talking to the Factory Server. The fact that Go bindings only use Client speaks for itself. At the same time - just a refresher - the Faktory lingo has got a Client Vs Worker. So, if we decide to merge client with producer, we may want to rename the Consumer to be Worker, wdyt?

I believe, though, the current setup IS semantically correct.

[jonhoo]

Yeah, that's my thinking too: Producer -> Client, Consumer -> Worker, and have tracking just be additional methods on Client. After all, there's not really any difference between a client that submits jobs and one that tracks them.

[rustworthy]

Worth highlighting the change I made in 6c98127 too. I also decided to do that because it meant my editor kept changing the uses, and then the job requires that I run a manual command to change them back, which became tedious pretty quickly 😅

Hmm the idea was to never have to return to the question of 'use's grouping :), where the pipeline job would be the guard, rather than a reviewer. Anyhow, it was 1) a nit and 2) a nice nightly feature to learn about 🔬

[rustworthy]

Yeah, that's my thinking too: Producer -> Client, Consumer -> Worker, and have tracking just be additional methods on Client. After all, there's not really any difference between a client that submits jobs and one that tracks them.

Will be addressed in #49