Reusing the original query is hard, and the case you have is due to
mismatched entities that would have to be handled, probably by wrapping the
original query in a subquery just like subquery eager loading does. The
subquery eager loading feature took a few years to work out an enormous
number of
Hey Mike,
Thanks for those -- seems to have helped those cases, though we're running
into some pretty weird behavior with joins. Here's a simplified case that
shows one of the issues we're running into (use _loader_from_cls from
above):
class W(Base):
__tablename__ = 'w'
id = Column(I
SQLAlchemy release 1.1.9 is now available.
A continuing stream of small regressions is leading us to have to put
out releases every few days at the moment. This release includes a fix
to a regression that was caused by a fix to a regression :),
specifically the sqlalchemy.ext.mutable fix put
On 04/04/2017 09:29 AM, Luca Wehrstedt wrote:
Your demo works correctly on my end as well, but it doesn't really mimic
the way I'm using that CodenameConstraint. What I'm doing is similar to
the following:
t = Table(
't', m, Column('x', String, CodenameConstraint('x'))
)
And if I re-run
This repaste of the example contains two refinements to address each of
these issues distinctly. We want to avoid re-entrant invocation of
_loader_for_cls, so putting a flag into attributes handles that. Then
there's the issue of same class coming in that we are already querying,
we can look
Your demo works correctly on my end as well, but it doesn't really mimic
the way I'm using that CodenameConstraint. What I'm doing is similar to the
following:
t = Table(
't', m, Column('x', String, CodenameConstraint('x'))
)
And if I re-run your demo with this modification I get as output
When you build a literal like that in an expression, it defaults to
being placed inside a bindparam() object, which under SQL compilation
will do the parameter thing you are seeing.
However, in the case of constraints like CheckConstraint, this behavior
is explicitly turned off in the base com
