On Sun, Aug 18, 2013 at 10:22 PM, Jay Pipes <jaypi...@gmail.com> wrote:
> 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. >> > +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@lists.openstack.**org <OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
