connection.queries没有任何回报

问题描述

从django.db导入连接，reset_queries


打印：[]

reset_queries()
p = XModel.objects.filter(id=id) \
.values('name') \
.annotate(quantity=Count('p_id'))\
.order_by('-quantity') \
.distinct()[:int(count)]
print(connection.queries)

同时打印：

reset_queries()
tc = ZModel.objects\
.filter(id=id, stock__gt=0) \
.aggregate(Sum('price'))
print(connection.queries)

我已经更改了字段名称，以使事情变得简单。 （字段是父表的，即 __ 到多个级别）


我试图打印Django生成的MySQL查询并遇到 connection.queries ，我想知道为什么它不首先打印为空，而第二个却可以正常工作。尽管我得到了结果，但我希望得到。可能查询已执行。

I have changed fields names to keep things simple. (Fields are of parent tables i.e. __ to multiple level)

I was trying to print MySQL queries that Django makes and came across connection.queries, I was wondering why doesn't it prints empty with first, while with second it works fine. Although I am getting the result I expect it to. Probably the query is executed. Also am executing only one at a time.

推荐答案

因为 QuerySet 是 lazy ：只要您不消费结果， QuerySet 不进行评估：不进行任何查询，直到您想要获取非 QuerySet 对象，例如 list s， dict ionaries， Model 对象等。

Because QuerySets in Django are lazy: as long as you do not consume the result, the QuerySet is not evaluated: no querying is done, until you want to obtain non-QuerySet objects like lists, dictionaries, Model objects, etc.

我们可以但是对于所有的ORM调用都不能这样做：例如 Model.objects.get（..）的类型为 Model 对象，我们不能推迟该获取（当然，我们可以将其包装在一个函数中，然后再调用它，但是 type是一个函数，而不是 Model 实例。

We can however not doe this for all ORM calls: for example Model.objects.get(..) has as type a Model object, we can not postpone that fetch (well of course we could wrap it in a function, and call it later, but then the "type" is a function, not a Model instance).

与 .aggregate（..）相同，因为结果是 dict ionary，将键映射到聚合的相应结果。

The same with a .aggregate(..) since then the result is a dictionary, that maps the keys to the corresponding result of the aggregation.

但是您的第一个查询是不需要评估。通过编写切片，您仅在查询末尾添加了 LIMIT 语句，但无需立即对其求值：此类型仍为 QuerySet 。

But your first query does not need to be evaluated. By writing a slicing, you only have added a LIMIT statement at the end of the query, but no need to evaluate it immediately: the type of this is still a QuerySet.

但是如果您调用 list（qs） QuerySet （ qs ），则表示 QuerySet

If you would however call list(qs) on a QuerySet (qs), then this means the QuerySet has to be evaluated, and Django will make the query.

QuerySet s的惰性也使这些链接成为可能。假设您编写：

The laziness of QuerySets also makes these chainings possible. Imagine that you write:

Model.objects.filter(foo=42).filter(bar=1425)

如果模型的 QuerySet 。 objects.filter（foo = 42）将会被立即评估，那么这可能会导致大量的 Model 实例，但是通过推迟此操作，我们现在也对 bar = 1425 进行了过滤（我们构造了 new QuerySet 同时考虑了 .filter（..） s）。这样可以提高查询效率，例如，可以减少必须从数据库传输到Django服务器的数据。

If the QuerySet of Model.objects.filter(foo=42) would be evaluated immediately, then this could result in a huge amount of Model instances, but by postponing this, we now filter on bar=1425 as well (we constructed a new QuerySet that takes both .filter(..)s into account). This can result in a query that can be evaluated more efficiently, and for example, can result in less data that has to be transferred from the database to the Django server.

这篇关于connection.queries没有任何回报的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！