Can you show the real code that runs the query? I'm wondering whether
the thing that you are comparing against my_table.c.name is not
actually a simple string.
Simon
On Wed, Feb 12, 2020 at 11:01 PM Mark Wilkins wrote:
>
> Some additional code incase its relevent:
>
> # Get DB connection
>
this looks like something up with the environment or the interpreter. The error
message says it got an object whose type() returns "BinaryExpression". that is
exactly the type it is looking for; this class should be a subclass of
sqlalchemy.sql.visitors.Visitable. However for this error to occur
I have a polymorphic class structure like this, with a lot of classes
extending the parent class.
In reality I'm using a Mixin that declares the visible_id column and it's
defined with @declared_attr.cascading, but for simplicity:
class A(Base):
__tablename__ = 'a'
id = Column(Intege
On Fri, Feb 14, 2020 at 5:35 PM Mark Aquino wrote:
>
> I have a polymorphic class structure like this, with a lot of classes
> extending the parent class.
> In reality I'm using a Mixin that declares the visible_id column and it's
> defined with @declared_attr.cascading, but for simplicity:
>
>
There's no point in really having the visible_id on the A table, other than
for inheritance.
The point of it being on B (and C, D, E, F, etc.) is that they have unique
sequences populating those "Visible IDs", so I have can have a B-1 and a
C-1 and a D-1.
In other words I have my parent table
There's no point in really having the visible_id on the A table, other than
for inheritance.
The point of it being on B (and C, D, E, F, etc.) is that they have unique
sequences populating those "Visible IDs", so I have can have a B-1 and a
C-1 and a D-1.
In other words I have my parent table
This is the actual code, with table names swapped out. I've confirmed that
my_table.c.name is infact a column, and the comparison operation generates
a BinaryExpression object as it is supposed to. The issue is that where()
throws an exception indicating it doesn't accept BinaryExpression object
This seems to be correct, the issue does not occur if I run the exact same
code locally. Lambda must be doing something, somehow, that is causing
this. Any advice on how to fix the problem?
On Friday, February 14, 2020 at 9:10:49 AM UTC-5, Mike Bayer wrote:
>
> this looks like something up with