本文旨在解决 Django `RawQuerySet` 中常见的 `ProgrammingError: "Error binding parameter 1: type 'builtin_function_or_method' is not supported"` 错误。该错误通常源于在参数绑定时，将局部变量名与 Python 内置函数名混淆。文章将深入分析错误原因，提供正确的参数绑定方法，并探讨在 Django 中使用 ORM 替代原生 SQL 查询的更优实践，以提高代码的可读性和维护性。
深入理解 RawQuerySet 参数绑定错误
在使用 Django 的 RawQuerySet 执行原生 SQL 查询时，开发者可能会遇到 ProgrammingError: "Error binding parameter 1: type 'builtin_function_or_method' is not supported" 错误。这个错误通常发生在尝试将参数绑定到 SQL 查询中，但传入的参数类型不正确时。
错误场景示例：
假设在 views.py 中有如下代码片段：
# views.py (原始问题代码示例)
if product.variant != "None":
variants = Variants.objects.filter(product_id=product.id)
colors = Variants.objects.filter(product_id=product.id, size_id=variants[0].size_id)
# 错误发生在这里的参数绑定
sizes = Variants.objects.raw("SELECT * FROM core_variants WHERE product_id=%s GROUP BY size_id",[id])
variant = Variants.objects.get(id=variants[0].id)
context = {'sizes': sizes,
'colors': colors,
'variant': variant,
}
return render(request, 'core/product-details.html', context)当 product-details.html 模板尝试迭代 sizes 变量时，就会触发上述 ProgrammingError：
错误原因分析：
问题的核心在于 Variants.objects.raw("...", [id]) 这一行。在 Python 中，id() 是一个内置函数，用于返回对象的“身份标识”。当代码中直接使用 [id] 而没有指定 product.id 时，Python 解释器会将 id 识别为内置的 id() 函数本身，而不是 product 对象的 id 属性值。
数据库驱动程序在尝试将 id() 函数对象（一个可调用类型 builtin_function_or_method）绑定到 SQL 查询的 %s 占位符时，发现其类型不受支持，从而抛出 ProgrammingError。它期望的是一个具体的值（如整数或字符串），而不是一个函数引用。
解决方案：正确绑定参数
要解决此问题，只需确保在 RawQuerySet 的参数列表中传递的是变量的实际值，而不是对内置函数的引用。将 [id] 替换为 [product.id] 即可：
# views.py (修正后的代码)
if product.variant is not None: # 推荐使用 'is not None' 而非 '!= "None"'
variants = Variants.objects.filter(product_id=product.id)
colors = Variants.objects.filter(
product_id=product.id, size_id=variants[0].size_id
)
# 修正：使用 product.id 传递产品ID值
sizes = Variants.objects.raw(
'SELECT * FROM core_variants WHERE product_id=%s GROUP BY size_id',
[product.id],
)
variant = Variants.objects.get(id=variants[0].id)
context = {
'sizes': sizes,
'colors': colors,
'variant': variant,
}
return render(request, 'core/product-details.html', context)通过这一修改，product.id 的实际整数值将被正确地绑定到 SQL 查询的 product_id 占位符，从而避免了类型错误。
最佳实践与 ORM 替代方案
尽管 RawQuerySet 在某些复杂场景下非常有用，但在许多情况下，Django ORM 提供了更安全、更易读且通常更高效的替代方案。对于本例中获取按 size_id 分组的 Variants 数据，使用 ORM 可以避免原生 SQL 的潜在陷阱，并更好地利用 Django 的抽象能力。
考虑到模板中 {{rs.size_id.title}} 的用法，rs.size_id 似乎是一个指向 Size 模型的 ForeignKey。因此，获取与产品相关联的所有独特 Size 对象是更符合逻辑的需求。
使用 Django ORM 实现相同功能：
我们可以通过链式查询和 distinct() 方法来获取与特定产品相关的所有独特 Size 对象：
# views.py (使用 ORM 替代 RawQuerySet)
from django.db.models import F
if product.variant is not None:
# 获取与产品关联的所有变体
all_variants_for_product = Variants.objects.filter(product_id=product.id)
# 获取所有独特的尺寸（Size对象），通过 Variants 模型反向查询
# 假设 Variants 模型有一个 ForeignKey 到 Size 模型，名为 'size' 或 'size_id'
# 如果 size_id 直接是字段，且需要获取关联的 Size 对象，可以这样：
# sizes = Size.objects.filter(variants__product_id=product.id).distinct()
# 如果只是需要 Variants 对象本身，但按 size_id 去重（PostgreSQL特有）
# sizes = Variants.objects.filter(product_id=product.id).order_by('size_id').distinct('size_id')
# 对于跨数据库兼容性，如果只是需要唯一的 size_id 值，可以这样：
distinct_size_ids = all_variants_for_product.values_list('size_id', flat=True).distinct()
# 然后获取对应的 Size 对象（假设存在 Size 模型）
# 假设 size_id 是 Variants 模型的一个 ForeignKey 到 Size 模型
from core.models import Size # 假设 Size 模型在 core 应用中
sizes = Size.objects.filter(id__in=distinct_size_ids)
# 获取特定尺寸的颜色变体
# 假设 all_variants_for_product 不为空
colors = all_variants_for_product.filter(size_id=all_variants_for_product.first().size_id)
# 获取第一个变体
variant = all_variants_for_product.first()
context = {
'sizes': sizes, # 现在 sizes 包含 Size 对象
'colors': colors,
'variant': variant,
}
return render(request, 'core/product-details.html', context)
注意事项：
- product.variant is not None: 在 Python 中，比较对象是否为 None 时，推荐使用 is None 或 is not None，而非 != "None"。
- ORM 效率: 使用 ORM 通常能更好地利用数据库索引和连接优化，同时降低 SQL 注入的风险。
- 减少数据库查询: 在原始代码中，对 Variants 模型进行了多次查询。可以考虑一次性获取所有相关变体，然后通过 Python 代码进行筛选，或者使用 select_related/prefetch_related 减少 N+1 查询问题。例如，all_variants_for_product = list(Variants.objects.filter(product_id=product.id)) 可以在一次查询中获取所有变体，后续操作直接在内存中的 all_variants_for_product 列表上进行。
总结
在 Django 开发中，RawQuerySet 是一个强大的工具，但使用时需格外小心参数绑定。ProgrammingError: "Error binding parameter 1: type 'builtin_function_or_method' is not supported" 错误是一个常见的陷阱，提醒我们必须区分 Python 内置函数与变量名。优先使用 Django ORM 可以有效避免这类问题，并提升代码的可读性、可维护性和安全性。当确实需要原生 SQL 时，请务必确保参数的类型和值正确无误。
