本文深入探讨了在Django中使用raw查询时，因误将Python内置函数id作为参数传入而导致的ProgrammingError。文章详细解释了该错误的根源，提供了正确的参数绑定方法，即使用具体的对象属性如product.id，并建议在多数情况下优先考虑Django ORM以提升代码的可读性和维护性，避免不必要的原始SQL查询。
理解ProgrammingError的根源：id函数与参数绑定
在Django开发中，当我们需要执行复杂的SQL查询而Django ORM无法直接满足时，Model.objects.raw()方法提供了一个强大的途径来执行原始SQL。然而，在使用此方法时，参数绑定是一个常见的陷阱。问题中出现的ProgrammingError: "Error binding parameter 1: type 'builtin_function_or_method' is not supported"错误，其核心原因在于将Python的内置函数id()误用作了SQL查询的参数。
Python内置的id()函数用于返回对象的“身份”，即其内存地址。当您在raw查询的参数列表中使用[id]时，Python解释器会将其解析为对内置id函数的引用，而不是您期望的产品ID值。数据库驱动程序在尝试将一个函数对象绑定到SQL查询的参数位置时，会因为无法识别其数据类型而抛出上述错误。
正确的做法是，如果您想传递某个特定对象的ID属性，例如product对象的ID，您应该明确地引用该属性，即product.id。
修正参数绑定错误
以下是修正后的views.py代码片段，展示了如何正确地将product的ID作为参数传递给raw查询：
from django.shortcuts import render
from .models import Variants, Product # 假设Product模型存在
def product_details_view(request, product_id): # 假设product_id从URL获取
# 获取产品对象，这里需要根据实际情况获取
try:
product = Product.objects.get(id=product_id)
except Product.DoesNotExist:
# 处理产品不存在的情况，例如返回404
pass
if product.variant is not None: # 假设product.variant是某种标识
variants = Variants.objects.filter(product_id=product.id)
# 确保variants列表不为空，以避免索引错误
if variants.exists():
first_variant_size_id = variants[0].size_id
else:
# 处理没有变体的情况，例如设置默认值或返回空列表
first_variant_size_id = None
colors = Variants.objects.filter(
product_id=product.id,
size_id=first_variant_size_id
) if first_variant_size_id else Variants.objects.none()
# 核心修正：使用 product.id 而非内置的 id 函数
sizes = Variants.objects.raw(
'SELECT * FROM core_variants WHERE product_id=%s GROUP BY size_id',
[product.id], # 正确的参数绑定
)
# 确保variants列表不为空
variant = Variants.objects.get(id=variants[0].id) if variants.exists() else None
else:
# 处理 product.variant 为 None 的情况
sizes = []
colors = []
variant = None
context = {
'sizes': sizes,
'colors': colors,
'variant': variant,
}
return render(request, 'core/product-details.html', context)
在上述代码中，关键的修改是将[id]替换为[product.id]。这确保了raw查询接收到的是product对象的实际ID值，而不是Python内置的id函数。
优化与最佳实践：优先使用Django ORM
尽管raw查询在某些特定场景下非常有用，但通常情况下，Django ORM提供了更安全、更易读且更具可维护性的解决方案。对于上述示例中的需求，即获取特定产品的所有变体，并按size_id进行分组，Django ORM可以很优雅地实现：
# 使用Django ORM实现按 size_id 分组
# 获取所有不重复的 size_id 及其相关信息
unique_sizes = Variants.objects.filter(product_id=product.id).values('size_id', 'size_id__title').distinct()
# 如果需要获取完整的 Variants 对象，但按 size_id 分组，可能需要更复杂的 ORM 查询
# 例如，获取每个 size_id 对应的第一个 Variant 对象
# 这种情况下，raw 查询可能确实更直接，但也可以通过子查询或窗口函数模拟对于获取按size_id分组的变体，并需要显示size_id的标题（假设size_id是一个外键到Size模型，并且Size模型有title字段），可以这样实现：
# 假设 Variants 模型有一个 ForeignKey 到 Size 模型，名为 'size'
# class Variants(models.Model):
# product = models.ForeignKey(Product, on_delete=models.CASCADE)
# size = models.ForeignKey(Size, on_delete=models.CASCADE)
# # ... 其他字段
# 获取所有不重复的尺寸及其标题
sizes = Variants.objects.filter(product_id=product.id).values('size__id', 'size__title').distinct()
# 在模板中迭代 sizes
# 注意事项：
- 避免变量名冲突： 在编写代码时，尤其是在函数或方法内部，应避免使用与Python内置函数（如id、list、dict、str等）相同的变量名，以防止混淆和意外行为。
- 安全性： 使用raw查询时，务必注意SQL注入风险。Django的raw方法会正确地对参数进行转义，但如果您拼接SQL字符串而不是使用参数绑定，则存在风险。始终使用参数绑定方式（如%s占位符和参数列表）。
- 可读性和维护性： 优先考虑使用Django ORM。ORM查询通常比原始SQL更易于理解和维护，并且在数据库迁移和抽象方面提供了更好的支持。只有当ORM无法满足复杂查询需求时，才考虑使用raw查询。
- 错误处理： 在访问查询集元素（如variants[0]）之前，务必检查查询集是否为空，以避免IndexError。
总结
ProgrammingError: "Error binding parameter 1: type 'builtin_function_or_method' is not supported"这一错误清晰地指出了在Django raw查询中参数绑定时，将Python内置函数id误用为数据值的常见问题。解决此问题的关键在于明确区分Python内置函数和对象属性，并确保在传递参数时使用正确的属性引用（例如product.id）。同时，本教程强烈建议开发者在多数情况下优先采用Django ORM进行数据库操作，以提高代码的健壮性、可读性和可维护性，仅在特定复杂场景下才考虑使用raw查询。
