both issues, same-named attributes on dual subclasses and structural subqueryloads in conjunction with with_polymorphic, are now repaired in the latest tip for 0.8 and both test scripts are functional in 0.8 now. Feel free to test it out and send me more feedback, thanks !
On Nov 23, 2012, at 1:49 PM, Martin84 wrote: > 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. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. 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.
