Open Stack

On Sun, Aug 18, 2013 at 10:22 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> 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.
>>
>
+1, I am hoping this will provide noticeable performance benefits while
being agnostic of what DB back-end is being used.  With the way we use
 SQLALchemy being 25x slower then MySQL we have lots of room for
improvement (see http://paste.openstack.org/show/44143/ from
https://bugs.launchpad.net/nova/+bug/1212418).



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


Nova is already moving in the direction of using
https://blueprints.launchpad.net/nova/+spec/unified-object-model
https://wiki.openstack.org/wiki/ObjectProposal which is currently built on
top of the procedural nova.db.api


>
> -jay
>
>
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130818/364d6639/attachment.html>