On Apr 11, 2019, at 7:55 AM, Chris Dent <cdent+os@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: https://storyboard.openstack.org/#!/story/2005435 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