← Back to team overview

nova team mailing list archive

Re: ORM Refactor


On 10-09-2010 18:56, Jay Pipes wrote:
> One of the things that both Justin and I had tried was to keep an
> abstraction layer that would allow both NoSQL as well as SQL data
> stores to be used.  Unfortunately, it seems that this patch removes
> the ability to use ReDIS, among other NoSQL stores.  I think this is a
> mistake, and although I like much of the code in this patch, I was
> hoping that SQLAlchemy could be hidden behind an abstraction layer
> that would play nicely with the non-relational data stores.

I must admit my experience with non-relational data stores is quite
limited and I've never had one hidden behind an ORM, so perhaps I'm
missing something, but I don't see what about this approach conflicts
with a non-relational approach?

> So...what to do?  There are at least four options I can see:
> 1) Go forward with this patch and add NoSQL stores back at some later
> time by ourselves
> 2) Go forward with this patch and wait until SQLAlchemy properly
> supports key value stores
> 3) Delay this patch until after the Austin release and have a larger
> discussion about it here and at the next summit
> 4) Go back to the drawing board and try again with a less ambitious
> set of patches that incrementally changes the way the data stores
> work.
> I'm personally on the fence.  I'd prefer to at least delay the patch
> until after Austin, but I understand there are now at least 4 branches
> that depend on this one, which makes things, well, a bit difficult.

Personally, I'm in favour of the patch for a couple of reasons:

 * I think it represents a major cleanup of the datastore access.
 * I like the abstraction.
 * I haven't identified much fallout as a result of the patch.
 * I too have implemented new features on top of it, and it really was a
 * Our datamodel happens to be quite relational.

Feature freeze is still weeks away and there's a good bit of time after
that just for fixing bugs. I think we're in a pretty good position to
make sure this doesn't have any ill effects. I think very little will be
gained by delaying the merge of this branch.

My only technical beef with this patch is that, as Vish points out
himself, it does lack a clear definition of the specifics of the
interface of the classes that come out of the DB implementation, but I
think that's the sort of thing that's better addressed once another
backend driver turns up.

Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/