Open Stack

On 19 August 2013 10:43, Jay Pipes <jaypipes at gmail.com> wrote:
> 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.

Thats not the ORM layer. The SQL dialect layer is a layer below the
ORM : the ORM is the layer that provides sql <-> model translation,
including the descriptors that make assignment and dereferencing
trigger SQL.

I'm completely with Joshua here - the ORM layer is more often than not
a source of bugs and performance issues.

> 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...

We don't use the SQLAlchemy ORM for cross-SQL-DB support - thats a
lower layer. It's the model objects themselves that we use the ORM
for, and we could use SQLAlchemy's lower layers but not the ORM.


> 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.

An alternative I think would be better would be to scrap the use of
the SQLAlchemy ORM; keep using the DB engine abstraction support.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud