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