[openstack-dev] [Glance] Replacing Glance DB code to Oslo DB code.
flavio at redhat.com
Mon Aug 19 09:15:16 UTC 2013
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.
>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...
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
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."
More information about the OpenStack-dev