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" <[email protected]<mailto:[email protected]>> wrote: On Sun, Aug 18, 2013 at 10:22 PM, Jay Pipes <[email protected]<mailto:[email protected]>> wrote: On 08/18/2013 09:56 PM, Robert Collins wrote: On 19 August 2013 10:43, Jay Pipes <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected]<mailto:[email protected]> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
