Open Stack

On 18/08/13 18:47 -0400, Jay Pipes wrote:
>On 08/18/2013 06:28 PM, Joe Gordon wrote:
>>
>>On Aug 18, 2013 3:58 PM, "Jay Pipes" <jaypipes at gmail.com
>><mailto: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.
>>
>> From what I have seen the issue is both the queries and the ORM layer.
>>See https://bugs.launchpad.net/nova/+bug/1212418  for details.
>
>Good point.
>
>For the record, I'm not a fan of lazy/eager loading of relations in 
>the models themselves, but instead always being explicit about the 
>exact data you wish to query for.
>
>It's similar in nature to the SQL best practice of never doing SELECT 
>* FROM <set> and instead of always being explicity about the columns 
>you wish to retrieve...
>

+1

I've seen a couple of cases where this is not being taken under
consideration. I'd like to see some of the lazy loaded relations being
explicitly loaded. 

I think a good rule for this is:

"If you know you'll need it, then load it. If you don't know it, then
you're *probably* doing something wrong."

Cheers,
FF

-- 
@flaper87
Flavio Percoco