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" <jaypi...@gmail.com> wrote: > On 08/18/2013 06:28 PM, Joe Gordon wrote: >> >> On Aug 18, 2013 3:58 PM, "Jay Pipes" <jaypi...@gmail.com >> <mailto:jaypi...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
