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 breeze. * 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/ _______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
