I'd be inclined to agree with Anssi that we could do something like LIMIT
21 to just remove the issues with large numbers. I have found it quite
helpful to have the exact number when it's small - especially when
debugging issues with strange joins etc.
On 4 June 2013 15:02, Jacob Kaplan-Moss wro
On Tue, Jun 4, 2013 at 1:48 AM, Anssi Kääriäinen
wrote:
> As for .get() - I don't find the number of duplicates in the error
> message that useful.
Yeah, I'd agree with that. It's another one of those things that goes
WAY back into the misty reaches of Django's history, but I don't think
there's
On 4 kesä, 00:22, Shai Berger wrote:
> On Monday 03 June 2013, Patryk Zawadzki wrote:
>
> > Here's the ticket:
>
> >https://code.djangoproject.com/ticket/6785
>
> > tl;dr: Calling .get() on a badly filtered queryset can result in lots
> > of database rows being fetched and wrapped in Python object
On Monday 03 June 2013, Patryk Zawadzki wrote:
> Here's the ticket:
>
> https://code.djangoproject.com/ticket/6785
>
> tl;dr: Calling .get() on a badly filtered queryset can result in lots
> of database rows being fetched and wrapped in Python objects for no
> gain.
>
tl;dr: There's a general,
Here's the ticket:
https://code.djangoproject.com/ticket/6785
tl;dr: Calling .get() on a badly filtered queryset can result in lots
of database rows being fetched and wrapped in Python objects for no
gain.
Currently .get() logic is as follows: clone the queryset, prepopulate
its full cache, chec
