[placement][ptg] code refactoring constraints and goals
On Apr 11, 2019, at 7:55 AM, Chris Dent <cdent+os at anticdent.org> wrote:
> My main reservation with this suggestion is that it moves some
> things in the opposite direction from what I would prefer: I'd like
> to see (file-based) separation between those methods which are
> `db_api.placement_context_manager` and those that are not. Or, in
> other terms: sql generation in other files.
> This would allow us to have what amounts to three tiers:
> * web stuff
> * mumble (might call it controller, but that's not quite right)
> * sql stuff
> which I feel provides good contextual cues and affords some
> opportunities for more robust testing of the sql generation.
> However, it might be more pain than it is worth as we currently have
> quite a bit of set() management mixed with sql management.
For a variety of reasons, most of which would be obvious given my previous enthusiasm for exploring alternatives, Iâ??ve proposed a story for refactoring out the DB-specific code from the rest of placement:
I donâ??t know what everyoneâ??s preference would be for where the DB code would go: either in private methods of the original module, or in a separate DB module, so I added as the first task coming to a decision on how to make that split.
-- Ed Leafe