本文深入探讨了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.pyif 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() 这种方式，你的模板代码可能需要相应调整：
{% for rs in sizes %} {# 这里的 rs 现在是 Size 对象 #} {{rs.title}} {% endfor %}
优化查询次数
原始代码中，为了获取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应用。
以上就是Django RawQueryset参数绑定错误及ORM优化实践的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1379065.html
微信扫一扫 
支付宝扫一扫 
