Open Stack

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). 

What are the benefits in your mind??

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.

Sent from my really tiny device...

On Aug 18, 2013, at 12:58 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:

> On 08/18/2013 03:53 AM, Joshua Harlow wrote:
>> I always just liked SQL as the database abstraction layer ;)
>> 
>> On a more serious note I think novas new object model might be a way to go but in all honesty there won't be a one size fits all solution. I just don't think sqlalchemy is that solution personally (maybe if we just use sqlalchemy core it will be better and eject just the orm layer).
> 
> What is specifically wrong with SQLAlchemy's ORM layer? What would you replace it with? Why would use SQLAlchemy's "core" be better?
> 
> I've seen little evidence that SQLAlchemy's ORM layer is the cause for database performance problems. Rather, I've found that the database schemas in use -- and in some cases, the *way* that the SQLAlchemy ORM is called (for example, doing correlated subqueries instead of straight joins) -- are primary causes for database performance issues.
> 
> Note, I'm not speaking about database scalability issues but rather pure query performance...
> 
> Best,
> -jay
> 
>> On Aug 16, 2013, at 12:07 PM, "Jay Pipes" <jaypipes at gmail.com> wrote:
>> 
>>> On 08/16/2013 02:41 PM, Mark Washenberger wrote:
>>>> I think the issue here for glance is whether or not oslo common code
>>>> makes it easier or harder to make other planned improvements. In
>>>> particular, using openstack.common.db.api will make it harder to
>>>> refactor away from a giant procedural interface for the database driver.
>>> 
>>> And towards what? A giant object-oriented interface for the database driver?
>>> 
>>> -jay
>>> 
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev