本文深入探讨了在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 renderfrom .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# # {% for item in sizes %}# {{ item.size__title }}# {% endfor %}#
注意事项：
避免变量名冲突： 在编写代码时，尤其是在函数或方法内部，应避免使用与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查询。
以上就是解决Django Raw Queryset参数绑定错误：避免id内置函数陷阱的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1379343.html
微信扫一扫 
支付宝扫一扫 
