It would be neat to see what would happen if just the "raw" models were just used directly. Of course this must be treaded careful since I could see it spreading db logic all over.
+1 for turning off deferred loads, I think this encourages and actually hides bugs when lazy loads occur on demand. I have seen this become an issue for taskflow usage where the results of tasks can not be saved to persistent storage due to deferred loading actually affected a feature in another module (the 'key in model' behaves differently than with dicts). Sent from my really tiny device... On Aug 18, 2013, at 3:46 PM, "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. > > 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... > >> What are the benefits in your mind?? > > There are not many benefits to ORMs (IMO) other than the abstraction of > underlying storage systems. I think it's unfortunate that -- due to the very > early use/support of Redis as the backend storage system for Nova -- that the > uber-abstraction DB API (as Mark W points out... a procedural API) exists in > Nova, Cinder, and other projects. Other than Keystone and Ceilometer, which > need to support non-RDBMS storage backends like LDAP or MongoDB, I would have > thought the SQLAlchemy abstraction layer and model would be perfectly fine as > *the* DB API in Nova, Glance, Cinder, etc. > > But alas, there's another API on top of the already-abstracted SQLAlchemy DB > API... > >> But this may just be me ranting since I don't like layers that seem to add >> little benefit, especially when most of the openstack projects put a big >> procedural API.py (or more say in novas case) over the ORM layer anyway. > > Yeah, I don't like the additional API on top of the SQLAlchemy API either -- > procedural or not. For Keystone and Ceilometer, I can see the point of it. > For the other projects, I don't. > > 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. > > Best, > -jay > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > 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
