SQLAlchemy混合属性表达式Decimal格式化拼接TypeError原因及实现

为什么两个查询表现完全不同 #

• result_2 查询完整的SupplierDiscount ORM实体，访问disc_desc时直接走实例层的hybrid_property普通Python方法，全程在Python端完成字符串格式化，根本不会触发@disc_desc.expression装饰的数据库层逻辑，所以不会报错。
• result_1 将SupplierDiscount.disc_desc直接作为查询列传入，此时SQLAlchemy会调用对应的expression层方法，把方法返回的结果拼到SQL语句里下推给数据库执行。问题就出在expression方法里直接用了Python原生f-string：cls.discount * 100 此时根本不是Python端的Decimal数值，只是SQLAlchemy的BinaryExpression抽象对象（仅代表数据库字段做乘法的运算结构）。Python f-string格式化这类对象时，会自动调用对象的__format__方法传入.4f格式串，而BinaryExpression完全不支持这类数值格式化规则，因此抛出TypeError。

正确实现方式 #

hybrid property的expression层核心作用是生成可下推到数据库执行的SQL表达式，不能直接用Python原生字符串格式化语法处理SQL表达式对象，所有字符串拼接、数值格式化都要通过SQLAlchemy封装的SQL函数完成：

1. 导入SQLAlchemy的函数模块：

   from sqlalchemy import func
   

2. 重写expression层的实现，对齐实例层的输出格式：

   @disc_desc.expression
   def disc_desc(cls):
       return func.concat(
           cls.description,
           ': ',
           # 调用PostgreSQL内置to_char函数，将计算后的数值转为保留4位小数的字符串
           # FM修饰符用于去除输出的前导空格、多余填充，和Python端:.4f的输出效果完全匹配
           func.to_char(cls.discount * 100, 'FM99990.0000'),
           '%'
       )
   

常见误区提醒 #

• expression层方法在查询构建阶段就会执行，此时还没有从数据库拉取真实的业务数据，拿到的只是SQL表达式的结构对象，根本不存在实际的Decimal值，试图通过强制转float、转Decimal做格式化的操作本身就没有可执行的基础，自然会一直报错。
• 如果需要跨数据库适配，可将func.to_char替换为func.cast链式调用，将计算后的数值保留4位小数后转为字符串再拼接，实现跨库兼容。
• 原hybrid_property的实例层逻辑不需要调整，只要保证和数据库层的输出格式一致即可。

内容的提问来源于stack exchange，提问作者aik3e