Ah ha!
I figured this out. It was a mix of a lazy eye and some peculiarities
between Postgres(live) and sqlite(test-case).
Given the query:
session.query(Foo).options(contains_eager('bar')).order_by(Foo.id.desc()).offset(0).limit(100).all()]
The SQL is (approx)
select foo.*, bar.*
On Friday, October 30, 2015 at 11:38:50 AM UTC-4, Michael Bayer wrote:
> you wouldn't typically want to specify contains_eager('bar') if the SQL
> has no JOIN in it, which you'd do with query.join().
There's no valid reason for using the `contains_eager` here -- it's just a
typo.
I
On 10/29/15 7:54 PM, Jonathan Vanasco wrote:
>
>
> The difference is between these 2 forms:
>
> [(f.id, f.bar_id) for f in
> session.query(Foo).options(joinedload('bar')).order_by(Foo.id.desc()).offset(0).limit(100).all()]
> [(f.id, f.bar_id) for f in
>
I've spent an hour trying to reproduce this bug and can't. I'm hoping
someone can suggest what might be going on so I can make this reproducable
for a bug report
I have 2 classes:
class Foo(Base):
__tablename__ = 'foo'
id = Column(Integer, primary_key=True)
bar_id
On 10/29/15 6:50 PM, Jonathan Vanasco wrote:
> I've spent an hour trying to reproduce this bug and can't. I'm hoping
> someone can suggest what might be going on so I can make this
> reproducable for a bug report
>
> I have 2 classes:
>
> class Foo(Base):
> __tablename__ = 'foo'
On Thursday, October 29, 2015 at 7:33:47 PM UTC-4, Michael Bayer wrote:
>
> i dont have an immediate answer, though i wonder why you aren't using
> ~Bar.is_x.is(True) for that "IS NOT"...
>
Old habits and styleguide. The `~` ended up being missed on too many
glances and code-reviews.
>
