Open Stack

On 08/18/2013 06:08 PM, Joshua Harlow wrote:
> In my opinion (and just an opinion that I know everyone doesn't share) ORM layers are bulky, restrictive and overly complicate and confuse the reader of the code (code is read more often than written) and require another layer of understanding (a layer is useful if it adds good value, I am not sure sqlalchemy ORM layer does add said value).

The usefulness of SQLAlchemy in this case is its ability to abstract 
away the different database backends used in both development and 
production environments (SQLite, MySQL, and PostgreSQL typically, though 
I'm sure folks are running on other backends). The usefulness of the ORM 
over raw SQL is, of course, the ability for the ORM to provide a 
singular interface for the different SQL dialects that those underlying 
backends support.

If everyone was using PostgreSQL or everyone was using MySQL, there'd be 
less of a point to using an ORM like SQLAlchemy's. Instead, you'd use a 
simple db abstraction class like what's in Swift (which only uses 
SQLite). But, one of OpenStack's design principles is to be as agnostic 
as possible about underlying deployment things like database or MQ 
infrastructure, and one of the ramifications of that is abstraction 
layers...

> What are the benefits in your mind??

There are not many benefits to ORMs (IMO) other than the abstraction of 
underlying storage systems. I think it's unfortunate that -- due to the 
very early use/support of Redis as the backend storage system for Nova 
-- that the uber-abstraction DB API (as Mark W points out... a 
procedural API) exists in Nova, Cinder, and other projects. Other than 
Keystone and Ceilometer, which need to support non-RDBMS storage 
backends like LDAP or MongoDB, I would have thought the SQLAlchemy 
abstraction layer and model would be perfectly fine as *the* DB API in 
Nova, Glance, Cinder, etc.

But alas, there's another API on top of the already-abstracted 
SQLAlchemy DB API...

> But this may just be me ranting since I don't like layers that seem to add little benefit, especially when most of the openstack projects put a big procedural  API.py (or more say in novas case) over the ORM layer anyway.

Yeah, I don't like the additional API on top of the SQLAlchemy API 
either -- procedural or not. For Keystone and Ceilometer, I can see the 
point of it. For the other projects, I don't.

My point to Mark W was not that I preferred a procedural approach to an 
object-oriented one. My point was that I would hope that the direction 
was not to swap out the procedural abstraction DB API for an 
object-oriented one; instead, we should scrap the entire abstraction DB 
API entirely...and just use SQLAlchemy.

Best,
-jay