#6785: QuerySet.get() should only attempt to fetch a limited number of rows
-------------------------------------+-------------------------------------
Reporter: deadwisdom | Owner: nobody
Type: | Status: new
Cleanup/optimization | Version: master
Component: Database layer | Resolution:
(models, ORM) | Triage Stage: Accepted
Severity: Normal | Needs documentation: 0
Keywords: | Patch needs improvement: 1
Has patch: 0 | UI/UX: 0
Needs tests: 0 |
Easy pickings: 0 |
-------------------------------------+-------------------------------------
Changes (by akaariai):
* needs_better_patch: 0 => 1
* has_patch: 1 => 0
Comment:
Yes, optimizing the successful case is important. The .get() method can be
used in try-except workflows, but I don't know of any realistic use case
where the try-except is interested in multiple objects returned case.
The question is how much overhead the LIMIT 21 clause adds for get() on
databases that support it. If it doesn't add overhead, then keeping the
current behavior on databases that support LIMIT seems OK to me. If it
adds overhead, then lets just get rid of the LIMIT clause and close this
ticket as wontfix. As said before we can get rid of the clone overhead
easily, so that isn't a factor in deciding what to do here.
--
Ticket URL: <https://code.djangoproject.com/ticket/6785#comment:10>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.152ff1f2d8a087db5af3c3e3d55a9439%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
