Would James' suggestion of reusing the result cache in __repr__ have solved
your issue? I would like to see that first.

I'm not against the DEBUG-only fetching but there hasn't been any
suggestion what to show instead that could be of use.

One can also mitigate against bad queries particularly well by setting a
statement timeout at the database level (at least MySQL and PostgreSQL
support this), which most users will generally want at a scale where repr()
becomes a problem.

On Tue, 23 Mar 2021 at 12:40, Joachim Jablon <ewjoac...@gmail.com> wrote:

> Just been bitten by that same bug (combination of Sentry, using a
> Queryset.as_manager() that creates an unfiltered queryset as a local
> variable in the stack, a create signal that errored provoking a stacktrace
> that contained the queryset, a table that is always filtered by a field,
> and sorted by another field and an index that behaves poorly without the
> aformentionned filter).
>
> So would a contribution that would avoid evaluating the uncached queryset
> on repr when DEBUG is False likely to be accepted ? If so, I'm ready to get
> my hands dirty :)
>
> Cheers !
>
> Le dimanche 7 mars 2021 à 00:54:56 UTC+1, mic...@turbosys.com.br a écrit :
>
>> I agree with Matt on that. Avoiding executing the queries on production
>> would be helpful!
>>
>> Let me share my case. I use django-rest-framework in a specific project
>> and DRF has a feature: a serializer has a fancier string representation
>> when printed. I was using a serializer with a queryset in a view that had
>> an exception further, which caused the serializer to be logged and thus,
>> the queryset to be executed.
>>
>> There are more details in this discussion:
>> https://github.com/encode/django-rest-framework/discussions/7782
>>
>> The short story is: I was logging this serializer passively and it was
>> causing the execution of a query to a whole table with millions of records,
>> without any sorting optimization, creating hard to debug performance
>> problems.
>>
>> I understand it is an unusual situation, but repeating Matt's words:
>> Django should be reliable in production for any combination of those
>> conditions.
>>
>> Thanks!
>>
>> On Sunday, October 20, 2019 at 4:47:25 PM UTC-3 Matt wrote:
>>
>>> Perhaps we ought to just keep the current behavior when DEBUG is True
>>> (it seems so obvious now, I can't believe it wasn't the first thing I
>>> suggested)? Django does lots of helpful things in DEBUG mode at the expense
>>> of performance. I think this would be an innocuous change for most people.
>>>
>>> It is not the most important thing to remove behavior that most of users
>>>> use because we want to fix an edge case that was reported twice in the last
>>>> six years.
>>>>
>>>
>>> I don't consider any of those *individual *conditions to trigger the
>>> problem "off the beaten path" for a bigger production Django site. All of
>>> them *combined *is obviously extremely rare, but it will effect someone
>>> else eventually*. *It doesn't sit well with me to not fix the issue.
>>> Django should be reliable in production for any combination of those
>>> conditions.
>>>
>>> On Wednesday, October 16, 2019 at 12:14:37 AM UTC-7, Mariusz Felisiak
>>> wrote:
>>>>
>>>> W dniu środa, 16 października 2019 07:53:05 UTC+2 użytkownik Harro
>>>> napisał:
>>>>>
>>>>> Yes, it's a complicated issue, but isn't the SQL query the ultimate
>>>>> representation of which methods are called or not?
>>>>>
>>>>> Having the query evaluated during debugging has been shown to be
>>>>> harmful in certain situations, isn't that the most important thing to fix?
>>>>>
>>>>
>>>> Current behavior is extremely valuable IMO. It is not the most
>>>> important thing to remove behavior that most of users use because we want
>>>> to fix an edge case that was reported twice in the last six years. I agree
>>>> that we can clarify this in docs. SQL query is not a solutions because not
>>>> all of ORM users know SQL. Moreover the current `repr()` shows values from
>>>> DB that we'll miss showing only SQL. You can check in the Django
>>>> documentation how users use the current `repr()` e.g. in tutorials.
>>>>
>>>> Best,
>>>> Mariusz
>>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/050a8686-eaa5-47e7-a9ab-d8dd6fd14844n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/050a8686-eaa5-47e7-a9ab-d8dd6fd14844n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1ApjezaMS75cjTXnOwGjrj3SAoZT1VxHR%3DPCZfHec4XA%40mail.gmail.com.
  • Re:... Michel Sabchuk
    • ... Joachim Jablon
      • ... 'Adam Johnson' via Django developers (Contributions to Django itself)
        • ... 'Kevin Weaver' via Django developers (Contributions to Django itself)
          • ... Ian Foote

Reply via email to