Open Stack

Using an ORM how does the ORM know what attributes u might access (forgive me if this is a documented sqlalchemy pattern/solution). Doesn't it have to give u back the full model since the ORM layer can't predict what u might do with the model object?

Sent from my really tiny device...

On Aug 18, 2013, at 3:50 PM, "Jay Pipes" <jaypipes at gmail.com> 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...
> 
> Best,
> -jay
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev