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. I'm completely with Joshua here - the ORM layer is more often than not a source of bugs and performance issues. > 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. > 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. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
