[openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.

Joe Gordon joe.gordon0 at gmail.com
Mon Aug 19 02:33:56 UTC 2013

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

> 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://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>

More information about the OpenStack-dev mailing list