thanks, stick to 0.7 for now, http://www.sqlalchemy.org/trac/ticket/2617.
On Nov 26, 2012, at 5:45 AM, Martin84 wrote: > Hi Michael Bayer, > > maybe I found a further sqlalchemy bug. If you add to the human<->houses > relationship a lazy='subquery' parameter, then sqlalchemy throws an keyerror. > Check this script: http://pastebin.com/2ihWMZBA > > > > > 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/-/ca3VNEWRfoMJ. > To post to this group, send email to sqlalchemy@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > 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 sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
