本文深入探讨了django `rawqueryset`在使用过程中常见的参数绑定错误，特别是`programmingerror: type 'builtin_function_or_method' is not supported`。通过分析错误根源——误将python内置`id`函数作为参数传入，文章提供了正确的参数传递方法。同时，强调了在多数情况下优先使用django orm的优势，并给出了将复杂sql查询转换为安全、高效orm表达式的实践方案，旨在提升代码的健壮性与可维护性。
Django Raw Queries中的参数绑定错误解析
在Django开发中，RawQueryset提供了一种直接执行SQL查询并返回模型实例的能力，这在处理复杂查询或优化性能时非常有用。然而，使用RawQueryset也需要特别注意参数的绑定方式，否则可能引发意想不到的错误。
RawQueryset 的作用与风险
RawQueryset允许开发者绕过ORM，直接编写原生SQL语句。它的优点在于灵活性高，可以执行ORM难以表达的复杂查询。但与此同时，它也带来了潜在的风险：
- SQL注入风险：如果参数未正确绑定，直接拼接字符串可能导致SQL注入。
- 数据库兼容性：原生SQL可能不具备跨数据库的兼容性。
- 可读性与维护性：相比ORM，原生SQL可能降低代码的可读性和维护性。
ProgrammingError: type 'builtin_function_or_method' is not supported 错误分析
当你在使用RawQueryset时遇到ProgrammingError: type 'builtin_function_or_method' is not supported这样的错误，通常是因为你错误地将一个Python内置函数或方法本身作为参数传递给了SQL查询，而不是该函数执行后的返回值或一个具体的数据值。
在提供的代码示例中：
sizes = Variants.objects.raw("SELECT * FROM core_variants WHERE product_id=%s GROUP BY size_id",[id])这里的错误在于 [id]。Python中有一个内置函数叫做 id()，它的作用是返回对象的“身份”或内存地址。当你直接写 id 而不带括号时，你传递的不是一个具体的整数值（如product.id），而是Python内置的 id 函数对象本身。数据库驱动程序在尝试将这个函数对象绑定到SQL查询的参数位置时，发现它不是一个可支持的数据类型（如字符串、整数、日期等），因此抛出了 ProgrammingError。
正确的做法是传递一个具体的变量值，例如当前产品实例的ID，即 product.id。
修正参数绑定
要解决上述问题，只需将 [id] 替换为 [product.id]，确保传递的是一个具体的整数值，而不是内置函数 id。
修正后的代码片段如下：
# views.py
if product.variant is not None: # 优化了条件判断，使用 is not None 更符合Python习惯
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',
[product.id], # 将 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)最佳实践：优先使用Django ORM
尽管RawQueryset在特定场景下有其价值，但Django的ORM（Object-Relational Mapper）通常是更优的选择。ORM提供了更高级别的抽象，不仅能有效防止SQL注入，还能提高代码的可读性、可维护性和数据库的可移植性。
ORM的优势
- 安全性：ORM会自动处理参数绑定，有效防止SQL注入。
- 可读性与可维护性：使用Python对象和方法操作数据库，代码更符合Pythonic风格，易于理解和维护。
- 数据库可移植性：ORM代码无需修改即可在不同数据库后端（如PostgreSQL, MySQL, SQLite）之间切换。
- 性能优化：Django ORM提供了许多优化工具，如select_related、prefetch_related、annotate等，帮助开发者编写高效的数据库查询。
ORM替代方案：获取去重尺寸信息
原先的RawQueryset 'SELECT * FROM core_variants WHERE product_id=%s GROUP BY size_id' 意图是获取某个产品下所有不同的尺寸（size_id），并且可能需要这些尺寸对应的某个变体信息。然而，SELECT * 与 GROUP BY 的组合在许多数据库中（尤其是在严格模式下）是具有歧义的，因为*中的其他字段在GROUP BY后其值是不确定的。
如果 size_id 是一个指向 Size 模型的 ForeignKey，并且我们想要获取与产品关联的所有不重复的 Size 对象，可以使用以下ORM查询：
# 假设 Variants 模型中 size_id 是指向 Size 模型的 ForeignKey
# 获取与当前产品关联的所有不重复的尺寸对象
from core.models import Size # 假设 Size 模型在 core 应用中
# 方案一：通过 Variants 反向查询 Size
# 这种方式直接获取 Size 对象，更符合语义
distinct_sizes = Size.objects.filter(variants__product_id=product.id).distinct()
# 方案二：如果只需要 size_id 和 size_id.title，可以通过 Variants 模型进行聚合
# 注意：这种方式返回的是字典列表，不是 Variants 对象
# 如果 size_id 是 ForeignKey，则 size_id__title 可以访问关联 Size 模型的 title 字段
distinct_sizes_data = Variants.objects.filter(product_id=product.id)\
.order_by('size_id__title')\
.values('size_id', 'size_id__title')\
.distinct()
# 如果 HTML 模板期望的是一个拥有 .size_id 和 .size_id.title 属性的对象
# 可以考虑创建一个简单的DTO (Data Transfer Object) 或直接使用 distinct_sizes
# 如果 distinct_sizes 是 Size 对象的 QuerySet，则在模板中 rs.id 和 rs.title 即可
# 假设 Size 模型有 id 和 title 字段
# 此时在模板中循环 distinct_sizes，使用 rs.id 和 rs.title如果使用 distinct_sizes = Size.objects.filter(variants__product_id=product.id).distinct() 这种方式，你的模板代码可能需要相应调整：
<select name="size" id="size" class="form-control">
{% for rs in sizes %} {# 这里的 rs 现在是 Size 对象 #}
<option {% if variant.size_id == rs.id %}selected{% endif %} value="{{rs.id}}">{{rs.title}}</option>
{% endfor %}
</select>优化查询次数
原始代码中，为了获取variants和colors，进行了多次相似的查询。这可以通过一次查询或更精细的过滤来优化。
# views.py 优化后的代码示例
if product.variant is not None:
# 一次性获取所有与产品相关的变体
all_product_variants = Variants.objects.filter(product_id=product.id)
if all_product_variants.exists(): # 确保有变体存在，避免索引错误
# 获取第一个变体作为基准
first_variant = all_product_variants.first()
# 根据第一个变体的 size_id 过滤颜色
colors = all_product_variants.filter(size_id=first_variant.size_id)
# 获取去重尺寸信息（假设 size_id 是 ForeignKey 到 Size 模型）
# 这里使用 ORM 获取 Size 对象，更符合 Pythonic 风格
from core.models import Size # 假设 Size 模型在 core 应用中
sizes = Size.objects.filter(variants__product_id=product.id).distinct()
# 获取第一个变体对象
variant = first_variant
else:
# 处理没有变体的情况，例如设置默认值或跳转
colors = []
sizes = []
variant = None # 或者一个默认的 Variants 对象
context = {
'sizes': sizes,
'colors': colors,
'variant': variant,
}
return render(request, 'core/product-details.html', context)通过上述优化，我们将多个独立的查询合并或简化，减少了数据库交互的次数，从而提高了应用的性能。
总结
在使用Django进行开发时，理解并正确处理数据库查询是至关重要的一环。本文着重强调了以下几点：
- 参数绑定准确性：在使用RawQueryset时，务必确保传递的是具体的数值或对象，而不是Python内置函数或方法本身，以避免ProgrammingError。
- ORM优先原则：在大多数情况下，优先使用Django ORM来执行数据库操作。它不仅提供了强大的抽象，还能有效提升代码的安全性、可读性和可维护性。
- 查询优化：通过合并相似查询、利用ORM提供的优化工具（如distinct()、values()等），可以显著减少数据库交互次数，提高应用性能。
遵循这些最佳实践，将有助于构建更健壮、高效且易于维护的Django应用。
