[openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.
robertc at robertcollins.net
Mon Aug 19 01:56:25 UTC 2013
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
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.
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the OpenStack-dev