If this behavior is a bug , I can build out a testcase. FWIW , I think
it's a bug.
class Foo :
id = int primary key
bar = relationship(bar)
baz = relationship(baz)
# hits the db
a = session.query( Foo ).get(1)
# doesn't hit the db
b =
On Feb 28, 2014, at 12:09 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
If this behavior is a bug , I can build out a testcase. FWIW , I think it's
a bug.
class Foo :
id = int primary key
bar = relationship(bar)
baz = relationship(baz)
#
On Friday, February 28, 2014 12:41:46 PM UTC-5, Michael Bayer wrote:
nope. get() means, “the SELECT may not happen”. eager loads are always
secondary to the fact that the row is being loaded. if you want to
definitely load the row, say filter_by(id…).first().
Poking at the source
On Feb 28, 2014, at 2:12 PM, Jonathan Vanasco jonat...@findmeon.com wrote:
On Friday, February 28, 2014 12:41:46 PM UTC-5, Michael Bayer wrote:
nope. get() means, “the SELECT may not happen”. eager loads are always
secondary to the fact that the row is being loaded. if you want to
On Friday, February 28, 2014 2:33:11 PM UTC-5, Michael Bayer wrote:
OK well it has to emit the SELECT for the primary row, but yes
populate_existing will overwrite, so really, just any equivalent of
query(User).filter_by(primary key).first() is really all you need here…we
used to have a
