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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
