On 08/18/2013 09:56 PM, Robert Collins wrote:
On 19 August 2013 10:43, Jay Pipes <jaypi...@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.
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.
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
