On Friday, December 16, 2016 at 12:01:04 PM UTC-5, Mike Bayer wrote:
>
> You need to be inside orm/strategies.py in JoinedEagerLoader where it
> deals with row_processor. The "path" variable will show which relationship
> it thinks it's loading.
>
>>
>>
PERFECT! thanks.
--
SQLAlchemy -
You need to be inside orm/strategies.py in JoinedEagerLoader where it deals
with row_processor. The "path" variable will show which relationship it
thinks it's loading.
On Dec 16, 2016 11:27 AM, "Jonathan Vanasco" wrote:
>
>
> On Friday, December 16, 2016 at 9:14:21 AM
On Friday, December 16, 2016 at 9:14:21 AM UTC-5, Mike Bayer wrote:
>
> Those aren't easy cases to debug. Isolating the behavior into a small
> test is the best first step, failing that you'd at least have echo set to
> debug , and you can watch the rows cone in. If it were me I'd then be
Those aren't easy cases to debug. Isolating the behavior into a small test
is the best first step, failing that you'd at least have echo set to debug
, and you can watch the rows cone in. If it were me I'd then be pdb'ing,
but I realize that's because I know the eagerload mechanics pretty well.
I've got an edge-case that I can't reliably reproduce yet, and it's driving
me crazy.
I have a table/view that is used for an analytics report. It just
references 2 objects from a given table, along with a count.
class Report(Base):
__tablename__ = 'report'
id = Column(Integer,