workers using *state.State

[Menno Smits]

Hey Will,

FWIW, I'm responsible for 2 of them - dblogpruner and txnpruner. They were
created before I'd ever heard anything about workers not using *state.State
directly, certainly before the recent push to clean such workers up.
They're not all that new and weren't created in violation of explicit
instructions (the instructions came later).

When I created these workers I looked at the existing code and saw that
workers which only ran within the state servers used State directly so
that's what I did. These workers are very much state server specific so it
seemed sensible to take this approach.

I will update these workers to go via the API and cards already exist on
our team's board. It's just a matter of finding time amongst everything
else.

- Menno







On 8 September 2015 at 19:12, William Reade <william.reade at canonical.com>
wrote:

> People keep writing them, in defiance of sane layering and explicit
> instructions, for the most embarrassingly trivial tasks
> (statushistorypruner? dblogpruner? txnpruner? *all* of those can and should
> pass through a simple api facade, not just dance off to play with the
> direct-db-access fairies.)
>
> There is no justification for *any* of those things to see a *state.State,
> and I'm going to start treating new workers that violate layering this way
> as deliberate sabotage attempts. Leads who have overseen the introduction
> of those workers, sort it out.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20150909/0636de23/attachment.html>