SQLAlchemy 2.0.36版本中IN操作符对列列表选择的回归问题分析

SQLAlchemy作为Python生态中最流行的ORM工具之一，其2.0.36版本引入了一个值得注意的行为变更，影响了开发者使用IN操作符对列列表进行查询的方式。本文将深入分析这一变更的技术背景、影响范围以及解决方案。

问题现象

在SQLAlchemy 2.0.35及更早版本中，开发者可以编写如下查询语句：

result = await session.execute(
    select(Actor.id).where(
        Actor.id.in_([Actor.id]),
    )
)

这段代码会生成预期的SQL语句：

SELECT actor.id FROM actor WHERE actor.id IN (actor.id)

然而在2.0.36版本中，同样的代码会抛出异常：

sqlalchemy.exc.ArgumentError: IN表达式需要列表、SELECT构造或绑定参数对象，但得到了[<sqlalchemy.orm.attributes.InstrumentedAttribute对象>]

技术背景分析

这一变更源于SQLAlchemy对类型系统的改进。在2.0.36版本中，开发团队为了增强类型提示支持，对IN操作符的参数检查逻辑进行了调整。原本的检查逻辑较为宽松，能够接受任何可转换为SQL元素的Python对象，而新版本则采用了更严格的类型检查。

这种变更在大多数情况下是有益的，可以提前捕获潜在的类型错误。但在特定场景下，如将ORM映射属性直接放入IN列表时，这种严格检查反而会阻止原本有效的SQL构造。

实际应用场景

虽然示例中的查询（WHERE id IN (id)）看起来没有实际意义（因为结果总是为真，除非涉及NULL值），但类似的语法在以下场景中确实有用：

1. 比较一个列是否等于多个其他列中的任意一个：

   select(Thing.id).where(Thing.id.in_([Thing.parent_id, Thing.another_id]))
   

2. 动态构建查询条件时，可能需要将列对象与其他值混合在同一个列表中

3. 某些高级SQL模式中，可能需要将列作为IN列表的元素

解决方案

SQLAlchemy团队已经意识到这一问题，并在后续版本中进行了修复。修复方案是改进了类型检查逻辑，采用更符合Python风格的"鸭子类型"检查方式（通过检查__clause_element__方法的存在性），而不是严格的类型匹配。

对于遇到此问题的开发者，建议：

1. 升级到包含修复的SQLAlchemy版本
2. 如果暂时无法升级，可以将列对象显式转换为SQL元素：

   from sqlalchemy import literal_column
   select(Actor.id).where(Actor.id.in_([literal_column("actor.id")]))
   

总结

这一案例展示了ORM框架在类型安全性和灵活性之间需要做出的权衡。SQLAlchemy团队通过快速响应和修复，既保持了类型系统的严谨性，又恢复了框架对灵活SQL构造的支持能力。对于开发者而言，理解ORM框架的内部机制有助于更好地应对类似的技术变更。