Open Stack

"Johannes Erdfelt" <johannes at erdfelt.com> said:

> On Thu, Dec 15, 2011, Kevin L. Mitchell <kevin.mitchell at rackspace.com> wrote:
>>      2. However, I violently disagree with the idea that the DB layer
>>         must return dicts.  It does not, even if you start talking about
>>         allowing use of other kinds of databases.  We can, and should,
>>         wrap these things in objects, upon which we can call methods
>>         that do things—i.e., we should, you know, actually use
>>         object-oriented programming.
> 
> What kinds of things?
> 
> I'm not against returning back a standardized object that provides
> __getattr__ so we don't have to use dict notation. Any database backend
> can do something similar easily.
> 
> I'm just trying to better understand what is object-oriented about the
> data returned from a database? What methods would we want to use?
> 
> JE

I think the OO approach gets interesting when we start thinking about instances as objects rather than as data records passed to monolithic manager interfaces.


For example, instead of the following snippet:

  instance = self.compute_api.get(<uuid>)
  self.compute_api.resize(instance, new_flavor)

I might do something more like

  instance = self.compute_api.get(<uuid>)
  instance.resize(instance, new_flavor)


This doesn't seem like a big deal probably--it isn't. But its powerful in that it has now separated out the interface for finding instances from the interface for interacting with a given instance. No longer do I need a single object that knows how to find _and_ how to talk to _all_ the instances in the system. That means we can be more flexible with less complicated code paths.

Now, I could also rewrite it as

  instance = self.instance_registry.get(<uuid>)
  instance.resize(instance, new_flavor)

And in this case, I'm now skipping the service-level middleman (compute_api) entirely. It also creates the possibility of dividing up the db api. No longer would we need a 9000+ function db.api--so I can stub in or fake out useful subsections of the db api with simple dependency injection rather than an arbitrarily long list of monkey-patches. We could also separate out the sqlalchemy/models.py as joins permit.

I'm not trying to promote anything here as a panacea, however. OO approaches like this just seem better to me because I think the big interfaces nova has right now are code smell. But I'm not sure that this flexibility is something that Nova really needs in the near future, so refactoring to this approach could be a wasted effort or harmful if done only partially.

For now dict-based consistency seems okay, although I'd also be in favor of turning off lazy-loading for good and fixing whatever breaks.