Open Stack

It will be I interesting to see how it works out in nova, correct me if I am wrong but nova has even more onion layers than other openstack projects.

For ex:

Nova compute <->unified object model <->rpc<->conductor<->sqlalchemy ORM model<->SQL<->your db

Is nova moving away from the ORM model or is the above somewhat right?

My opinion is still out on how this will all workout there and what it's impact will be in the end. Just I hope the onion layers are worth it in the end.

Sent from my really tiny device...

On Aug 18, 2013, at 7:37 PM, "Joe Gordon" <joe.gordon0 at gmail.com<mailto:joe.gordon0 at gmail.com>> wrote:




On Sun, Aug 18, 2013 at 10:22 PM, Jay Pipes <jaypipes at gmail.com<mailto: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<mailto: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<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
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/20130819/44620bd5/attachment.html>