Open Stack

On 08/18/2013 09:56 PM, Robert Collins wrote:
> 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.

OK, fair enough.

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

If used improperly, yep.

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

Hmmm, not quite... see below.

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

Just keep in mind that the Session and Query objects and their related 
APIs are in the SQLAlchemy ORM, not the SQLAlchemy Core.

But sure, ok.

But then I guarantee somebody is gonna spend a bunch of time writing an 
object-oriented API to the model objects because the ORM is very useful 
for the data modification part of the DB interaction.

Because people will complain about having to do this:

conn = engine.connection()
# instances is the sqlalchemy Table object for instances
inst_ins = instances.insert().values(blah=blah)
ip_ins = fixed_ips.insert().values(blah=blah)
conn.execute(ip_ins)
conn.execute(inst_ins)
conn.close()

instead of this:

i = Instance(blah=blah)
ip = FixedIp(blah=blah)
i.fixed_ips.append(ip)
session.add(u)
session.commit()

And so you've thrown the baby out with the bathwater and made more work 
for everyone.

-jay