<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>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. </div>
<div><br>
</div>
<div>For ex:</div>
<div><br>
</div>
<div>Nova compute <->unified object model <->rpc<->conductor<->sqlalchemy ORM model<->SQL<->your db</div>
<div><br>
</div>
<div>Is nova moving away from the ORM model or is the above somewhat right? </div>
<div><br>
</div>
<div>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.</div>
<div><br>
Sent from my really tiny device...</div>
<div><br>
On Aug 18, 2013, at 7:37 PM, "Joe Gordon" <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, Aug 18, 2013 at 10:22 PM, Jay Pipes <span dir="ltr">
<<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On 08/18/2013 09:56 PM, Robert Collins wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 19 August 2013 10:43, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 08/18/2013 06:08 PM, Joshua Harlow wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
In my opinion (and just an opinion that I know everyone doesn't share) ORM<br>
layers are bulky, restrictive and overly complicate and confuse the reader<br>
of the code (code is read more often than written) and require another layer<br>
of understanding (a layer is useful if it adds good value, I am not sure<br>
sqlalchemy ORM layer does add said value).<br>
</blockquote>
<br>
<br>
The usefulness of SQLAlchemy in this case is its ability to abstract away<br>
the different database backends used in both development and production<br>
environments (SQLite, MySQL, and PostgreSQL typically, though I'm sure folks<br>
are running on other backends). The usefulness of the ORM over raw SQL is,<br>
of course, the ability for the ORM to provide a singular interface for the<br>
different SQL dialects that those underlying backends support.<br>
</blockquote>
<br>
Thats not the ORM layer. The SQL dialect layer is a layer below the<br>
ORM : the ORM is the layer that provides sql <-> model translation,<br>
including the descriptors that make assignment and dereferencing<br>
trigger SQL.<br>
</blockquote>
<br>
</div>
OK, fair enough.
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm completely with Joshua here - the ORM layer is more often than not<br>
a source of bugs and performance issues.<br>
</blockquote>
<br>
</div>
If used improperly, yep.
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If everyone was using PostgreSQL or everyone was using MySQL, there'd be<br>
less of a point to using an ORM like SQLAlchemy's. Instead, you'd use a<br>
simple db abstraction class like what's in Swift (which only uses SQLite).<br>
But, one of OpenStack's design principles is to be as agnostic as possible<br>
about underlying deployment things like database or MQ infrastructure, and<br>
one of the ramifications of that is abstraction layers...<br>
</blockquote>
<br>
We don't use the SQLAlchemy ORM for cross-SQL-DB support - thats a<br>
lower layer. It's the model objects themselves that we use the ORM<br>
for, and we could use SQLAlchemy's lower layers but not the ORM.<br>
</blockquote>
<br>
</div>
Hmmm, not quite... see below.
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
My point to Mark W was not that I preferred a procedural approach to an<br>
object-oriented one. My point was that I would hope that the direction was<br>
not to swap out the procedural abstraction DB API for an object-oriented<br>
one; instead, we should scrap the entire abstraction DB API entirely...and<br>
just use SQLAlchemy.<br>
</blockquote>
<br>
An alternative I think would be better would be to scrap the use of<br>
the SQLAlchemy ORM; keep using the DB engine abstraction support.<br>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>+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 <a href="http://paste.openstack.org/show/44143/">http://paste.openstack.org/show/44143/</a> from <a href="https://bugs.launchpad.net/nova/+bug/1212418">https://bugs.launchpad.net/nova/+bug/1212418</a>).</div>
<div>
<div> <br>
</div>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
</blockquote>
<br>
</div>
Just keep in mind that the Session and Query objects and their related APIs are in the SQLAlchemy ORM, not the SQLAlchemy Core.<br>
<br>
But sure, ok.<br>
<br>
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.<br>
<br>
Because people will complain about having to do this:<br>
<br>
conn = engine.connection()<br>
# instances is the sqlalchemy Table object for instances<br>
inst_ins = instances.insert().values(<u></u>blah=blah)<br>
ip_ins = fixed_ips.insert().values(<u></u>blah=blah)<br>
conn.execute(ip_ins)<br>
conn.execute(inst_ins)<br>
conn.close()<br>
<br>
instead of this:<br>
<br>
i = Instance(blah=blah)<br>
ip = FixedIp(blah=blah)<br>
i.fixed_ips.append(ip)<br>
session.add(u)<br>
session.commit()<br>
<br>
And so you've thrown the baby out with the bathwater and made more work for everyone.</blockquote>
<div><br>
</div>
<div>
<div>Nova is already moving in the direction of using <a href="https://blueprints.launchpad.net/nova/+spec/unified-object-model">https://blueprints.launchpad.net/nova/+spec/unified-object-model</a> <a href="https://wiki.openstack.org/wiki/ObjectProposal">https://wiki.openstack.org/wiki/ObjectProposal</a> which
is currently built on top of the procedural nova.db.api</div>
</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
<br>
-jay</font></span>
<div class="">
<div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>OpenStack-dev mailing list</span><br>
<span><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a></span><br>
<span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br>
</div>
</blockquote>
</body>
</html>