Hi Diana & Michael Bayer, thanks a lot for your help and time. I will use the workaround or change the database schema. Good to know, that sqlalchemy has such a helpful community!
Bye Am Freitag, 23. November 2012 17:37:00 UTC+1 schrieb Michael Bayer: > > > On Nov 23, 2012, at 3:38 AM, Martin84 wrote: > > > Hi Diana & Michael Bayer, > > > > thanks for your help! > > So, you both use sqlalchemy 0.8 and I use 0.7.9 and that explains our > different SQL queries. > > Now, with the join_depth=1 parameter the unexplainable SQL queries > disappear and there is no more difference between lazy='subquery' and > subqueryload(). > > But unfortunately now there is an other and far more problematic issue, > the output of showDatabase is incorrect. > > > > I modify my showDatabase() function like this: > > > > def showDatabase(session): > > house = session.query(House).one() > > for resident in house.residents: > > print resident.myChildren > > > > and now only one resident have a children (the men), and the one from > the woman disappear! > > How is this possible? > > sorry, this is a actually an eagerloading bug, which has probably come up > before, but is now posted as http://www.sqlalchemy.org/trac/ticket/2614. > eager loading in conjunction with with_polymorphic has always been a > bleeding edge feature and in this case the internal attribute targeting > used by the ORM is seeing a conflict between ASubclassA.attr and > ASubclassB.attr. It will require a major rethink of some aspects of this > internal naming in order for this issue to be resolved. 0.8 has already > had many weeks of effort put into improving the with_polymorphic system, so > we are in better shape to attack such issues. > > you will get the correct results if you don't try to subqueryload both > same-named attributes at the same time. A workaround for now would be to > name the two relationships differently, the use a @property to proxy them > both: > > class A(..): > myChildrenA = relationship(...) > > @property > def myChildren(self): > return myChildrenA > > class B(..): > myChildrenB = relationship(...) > > @property > def myChildren(self): > return myChildrenB > > or alternatively, another suggestion is to use a database schema that does > not rely so heavily on long chains of joins in order to produce basic > results. > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To view this discussion on the web visit https://groups.google.com/d/msg/sqlalchemy/-/moyAu8IEYOUJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
