Open Stack

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:

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