Open Stack

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" <jaypipes at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev