blocks|key|1310316|text|这是一个有趣的问题，但对我来说，选项#2意味着过早优化。我不确定哪个性能更好，但在我看来，选项#1看起来和感觉上肯定更像蟒蛇。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1310317|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Interesting question, but for me option #2 reeks of premature optimisation. I'm not sure which is more performant, but option #1 certainly looks and feels more pythonic to me.

blocks|key|1525374|text|我没有任何Django的经验，但是选项#1清楚地告诉系统您请求的是1个对象，而第二个选项不是。这意味着选项#1可以更容易地利用缓存或数据库索引，特别是在您过滤的属性不能保证是唯一的情况下。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1525375|另外(再次推测)第二个选项可能必须创建某种结果集合或迭代器对象，因为filter()调用通常会返回许多行。您可以使用get()绕过它。|1525376|最后，第一个选项更短，并省略了额外的临时变量-虽然差别很小，但每一点都有帮助。|1525377|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

I can't speak with any experience of Django but option #1 clearly tells the system that you are asking for 1 object, whereas the second option does not. This means that option #1 could more easily take advantage of cache or database indexes, especially where the attribute you're filtering on is not guaranteed to be unique.

Also (again, speculating) the second option may have to create some sort of results collection or iterator object since the filter() call could normally return many rows. You'd bypass this with get().

Finally, the first option is both shorter and omits the extra temporary variable - only a minor difference but every little helps.

blocks|key|1310405|text|为get()提供了specifically+for+this+case。使用它。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1310406|选项2几乎就是get()方法在Django中的实际实现方式，所以应该没有“性能”差异(而且您正在考虑它的事实表明您违反了编程的一个基本规则，即试图在编写和分析代码之前对其进行优化--直到您有了代码并可以运行它，您才知道它将如何执行，而在此之前尝试优化是一条痛苦的道路)。|1310407|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.djangoproject.com/en/stable/ref/models/querysets/#django.db.models.query.QuerySet.get|1|https://docs.djangoproject.com/en/stable/topics/db/queries/#retrieving-a-single-object-with-get^0|1|5|1|5|0|9|Q|1|0|7|5|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]|$9|X|A|Y|1|Z]]|E|$]]|$1|F|3|G|5|6|7|10|8|@$9|11|A|12|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

<a href="https://docs.djangoproject.com/en/stable/ref/models/querysets/#django.db.models.query.QuerySet.get" rel="noreferrer"><code>get()</code></a> is provided <a href="https://docs.djangoproject.com/en/stable/topics/db/queries/#retrieving-a-single-object-with-get" rel="noreferrer">specifically for this case</a>. Use it.

Option 2 is almost precisely how the <code>get()</code> method is actually implemented in Django, so there should be no "performance" difference (and the fact that you're thinking about it indicates you're violating one of the cardinal rules of programming, namely trying to optimize code before it's even been written and profiled -- until you have the code and can run it, you don't know how it will perform, and trying to optimize before then is a path of pain).

blocks|key|1310431|text|%251是正确的。在Python中，异常与返回具有相同的开销。要获得简化的证明，您可以查看this。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1310432|2这就是Django在后端做的事情。如果未找到项或找到多个对象，get将调用filter并引发异常。|style|CODE|1310433|entityMap|0|LINK|mutability|MUTABLE|url|http://paltman.com/2008/jan/18/try-except-performance-in-python-a-simple-test/^0|17|4|0|0|W|3|12|6|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@$A|U|B|V|F|G]|$A|W|B|X|F|G]]|9|@]|C|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|I|$J|$5|K|L|M|C|$N|O]]]]

1 is correct. In Python an exception has equal overhead to a return. For a simplified proof you can look at <a href="http://paltman.com/2008/jan/18/try-except-performance-in-python-a-simple-test/" rel="noreferrer">this</a>.

2 This is what Django is doing in the backend. <code>get</code> calls <code>filter</code> and raises an exception if no item is found or if more than one object is found.

blocks|key|1310465|text|为什么要这么做呢？将4行替换为1个内置快捷方式。(这将自行尝试/排除。)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1310466|from+django.shortcuts+import+get_object_or_404

obj+=+get_object_or_404(MyModel,+id=1)|code-block|syntax|javascript|1310467|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Why do all that work? Replace 4 lines with 1 builtin shortcut. (This does its own try/except.)

<pre><code>from django.shortcuts import get_object_or_404

obj = get_object_or_404(MyModel, id=1)
</code></pre>

blocks|key|1525576|text|关于异常的更多信息。如果它们不被提高，它们几乎是零成本。因此，如果您知道可能会有一个结果，请使用异常，因为使用条件表达式时，无论发生什么情况，您都要支付每次检查的成本。另一方面，当它们被引发时，它们的成本比条件表达式要高一点，所以如果你希望不会有一些频率的结果(比如说，30%25的时间，如果内存有效的话)，那么条件检查被证明是更便宜的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1525577|但这是Django的对象关系映射，可能是到数据库的往返，甚至是缓存的结果，很可能会影响性能特征，所以更倾向于可读性，在这种情况下，既然您希望只有一个结果，就使用get()。|offset|length|style|CODE|1525578|entityMap^0|0|28|5|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Some more info about exceptions. If they are not raised, they cost almost nothing. Thus if you know you are probably going to have a result, use the exception, since using a conditional expression you pay the cost of checking every time, no matter what. On the other hand, they cost a bit more than a conditional expression when they are raised, so if you expect not to have a result with some frequency (say, 30% of the time, if memory serves), the conditional check turns out to be a bit cheaper. 

But this is Django's ORM, and probably the round-trip to the database, or even a cached result, is likely to dominate the performance characteristics, so favor readability, in this case, since you expect exactly one result, use <code>get()</code>.

blocks|key|1525630|text|您可以安装一个名为django-annoying的模块，然后执行以下操作：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1525631|from+annoying.functions+import+get_object_or_None

obj+=+get_object_or_None(MyModel,+id=1)

if+not+obj:
++++#omg+the+object+was+not+found+do+some+error+stuff|code-block|syntax|javascript|1525632|entityMap|0|LINK|mutability|MUTABLE|url|http://bitbucket.org/offline/django-annoying/^0|9|F|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@$A|R|B|S|1|T]]|C|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|C|$G|H]]|$1|I|3|-4|5|6|7|V|8|@]|9|@]|C|$]]]|J|$K|$5|L|M|N|C|$O|P]]]]

You can install a module called <a href="http://bitbucket.org/offline/django-annoying/" rel="noreferrer">django-annoying</a> and then do this:

<pre><code>from annoying.functions import get_object_or_None

obj = get_object_or_None(MyModel, id=1)

if not obj:
 #omg the object was not found do some error stuff
</code></pre>

blocks|key|1525660|text|选项1更优雅，但请确保使用try..except。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1525661|根据我自己的经验，我可以告诉你，有时你肯定数据库中不可能有超过一个匹配的对象，但仍然会有两个……(当然，当通过主键获取对象时除外)。|1525662|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Option 1 is more elegant, but be sure to use try..except.

From my own experience I can tell you that sometimes you're sure there cannot possibly be more than one matching object in the database, and yet there will be two... (except of course when getting the object by its primary key).

blocks|key|1310622|text|我建议使用不同的设计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1310623|如果要对可能的结果执行函数，可以从QuerySet派生，如下所示：http://djangosnippets.org/snippets/734/|offset|length|1310624|结果非常棒，你可以这样做：|1310625|MyModel.objects.filter(id=1).yourFunction()|code-block|syntax|javascript|1310626|在这里，filter返回一个空的queryset或者一个包含单个项目的queryset。您的自定义查询集函数也是可链接和可重用的。如果您想对所有条目执行此操作：MyModel.objects.all().yourFunction()。|style|CODE|1310627|它们也非常适合用作管理界面中的操作：|1310628|def+yourAction(self,+request,+queryset):
++++queryset.yourFunction()|1310629|entityMap|0|LINK|mutability|MUTABLE|url|http://djangosnippets.org/snippets/734/^0|0|X|13|0|0|0|0|28|10|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|F|3|G|5|6|7|17|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|18|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|19|8|@$D|1A|E|1B|O|P]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|1C|8|@]|9|@]|A|$]]|$1|S|3|T|5|J|7|1D|8|@]|9|@]|A|$K|L]]|$1|U|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

I suggest a different design.

If you want to perform a function on a possible result, you could derive from QuerySet, like this: <a href="http://djangosnippets.org/snippets/734/" rel="nofollow">http://djangosnippets.org/snippets/734/</a>

The result is pretty awesome, you could for example:

<pre><code>MyModel.objects.filter(id=1).yourFunction()
</code></pre>

Here, filter returns either an empty queryset or a queryset with a single item. Your custom queryset functions are also chainable and reusable. If you want to perform it for all your entries: <code>MyModel.objects.all().yourFunction()</code>.

They are also ideal to be used as actions in the admin interface:

<pre><code>def yourAction(self, request, queryset):
 queryset.yourFunction()
</code></pre>

blocks|key|1525725|text|我已经解决了这个问题，并发现选项2执行了两个SQL查询，对于这样一个简单的任务来说，这是多余的。请参阅我的注释：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1525726|objs+=+MyModel.objects.filter(id=1)+#+This+does+not+execute+any+SQL
if+len(objs)+==+1:+#+This+executes+SELECT+COUNT(*)+FROM+XXX+WHERE+filter
++++obj+=+objs[0]++#+This+executes+SELECT+x,+y,+z,+..+FROM+XXX+WHERE+filter
else:+
++++#+we+have+no+object!++do+something
++++pass|code-block|syntax|javascript|1525727|执行单个查询的等效版本为：|1525728|items+=+[item+for+item+in+MyModel.objects.filter(id=1)]+#+executes+SELECT+x,+y,+z+FROM+XXX+WHERE+filter
count+=+len(items)+#+Does+not+execute+any+query,+items+is+a+standard+list.
if+count+==+0:
+++return+None
return+items[0]|1525729|通过切换到这种方法，我能够大大减少我的应用程序执行的查询数量。|1525730|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I've played with this problem a bit and discovered that the option 2 executes two SQL queries, which for such a simple task is excessive. See my annotation:

<pre><code>objs = MyModel.objects.filter(id=1) # This does not execute any SQL
if len(objs) == 1: # This executes SELECT COUNT(*) FROM XXX WHERE filter
 obj = objs[0] # This executes SELECT x, y, z, .. FROM XXX WHERE filter
else: 
 # we have no object! do something
 pass
</code></pre>

An equivalent version that executes a single query is:

<pre><code>items = [item for item in MyModel.objects.filter(id=1)] # executes SELECT x, y, z FROM XXX WHERE filter
count = len(items) # Does not execute any query, items is a standard list.
if count == 0:
 return None
return items[0]
</code></pre>

By switching to this approach, I was able to substantially reduce number of queries my application executes.

blocks|key|1525777|text|很抱歉在这个问题上添加更多的内容，但我正在使用django分页器，并且在我的数据管理应用程序中，允许用户选择要查询的内容。有时，它是文档的id，但在其他情况下，它是返回多个对象的通用查询，即Queryset。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1525778|如果用户查询id，我可以运行：|1525779|Record.objects.get(pk=id)|code-block|syntax|javascript|1525780|这会在django的分页器中抛出一个错误，因为它是一个记录，而不是一个记录查询集。|1525781|我需要运行：|1525782|Record.objects.filter(pk=id)|1525783|它返回一个包含一项的查询集。那么分页器就可以正常工作了。|1525784|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|X|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

Sorry to add one more take on this issue, but I am using the django paginator, and in my data admin app, the user is allowed to pick what to query on. Sometimes that is the id of a document, but otherwise it is a general query returning more than one object, i.e., a Queryset.

If the user queries the id, I can run: 

<pre><code>Record.objects.get(pk=id)
</code></pre>

which throws an error in django's paginator, because it is a Record and not a Queryset of Records.

I need to run:

<pre><code>Record.objects.filter(pk=id)
</code></pre>

Which returns a Queryset with one item in it. Then the paginator works just fine.

I was having a debate on this with some colleagues. Is there a preferred way to retrieve an object in Django when you're expecting only one?

The two obvious ways are:

<pre><code>try:
 obj = MyModel.objects.get(id=1)
except MyModel.DoesNotExist:
 # We have no object! Do something...
 pass
</code></pre>

And:

<pre><code>objs = MyModel.objects.filter(id=1)

if len(objs) == 1:
 obj = objs[0]
else:
 # We have no object! Do something...
 pass
</code></pre>

The first method seems behaviorally more correct, but uses exceptions in control flow which may introduce some overhead. The second is more roundabout but won't ever raise an exception. 

Any thoughts on which of these is preferable? Which is more efficient?

Django filter versus get for single object?

数据管理

数据库

Django

Python

我和一些同事就这个问题进行了辩论。在Django中，有没有一种更好的方法来检索对象，而你只需要一个？两种显而易见的方式是：try:    obj = MyModel.objects.get(id=1)except MyModel.DoesNotExist:    # We have no object! Do some...

问单个对象的Django过滤器还是get？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单个对象的Django过滤器还是get？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问单个对象的Django过滤器还是get？
EN