I reviewed the patch that was originally created for this:
https://github.com/django/django/pull/1055/commits/7d53d428c0323a7eca93b7b56968a895b031e2ae Essentially, it only includes the results of the queryset in the repr *if* the QuerySet._result_cache has been populated. There is one minor thing I don't like about the particular implementation: it shows the empty list if the result cache is not populated. I think it should just show <QuerySet> instead of <QuerySet []>. That way you can differentiate between _result_cache=None, and _result_cache=[]. This is an OK approach, but the inconsistency in the representation smells a little off. RawQuerySet simply does: def __repr__(self): return "<%s: %s>" % (self.__class__.__name__, self.query) which is dead simple, and useful. I think it can be argued that QuerySet should be consistent with it (otherwise, why isn't RawQuerySet executing its SQL to show the repr?) Regarding other things that have been mentioned: I'm not too keen about introducing a setting for this behavior, or doing things differently in an interactive console. Django already has a lot of settings, and this seems like such a minor thing. And I don't know of any precedent for changing the behavior of Django in an interactive shell (and you can tell I'm not a fan of inconsistent behaviors). I'm going to re-open the ticket and hope other Django devs chime in. On Thursday, October 10, 2019 at 8:50:31 AM UTC-7, Matt wrote: > > repr(some_queryset) will execute the query and display some results from > the query. This is done because it's (somewhat) helpful for debugging. > > > https://github.com/django/django/blob/2a6f45e08e8cb8c7e5157915c378b453109424d2/django/db/models/query.py#L248 > > This has caused at least two people to scratch their heads about odd > queries being generated, and it crashed my production database yesterday. > > See #20393 <https://code.djangoproject.com/ticket/20393> and #30863 > <https://code.djangoproject.com/ticket/30863> > > Luke Plant has said: > > ... you have a conflict between the goal of being information rich and >> with *always* being useful for debugging. In general, automatically >> seeing the results is information rich and is useful in debugging, but >> sometimes it causes further problems. >> >> I have thought about it, and with this conflict of goals, I think we are >> going to have to err on the side of the current behaviour. It is possible >> to work around by not calling repr on QuerySets in your middleware, and >> there are too many people who will be upset (or have problems with their >> own debugging facilities) by changing this. >> > > One reason people love Django is because of its attention to things like > debug-ability. I can certainly see the argument here. However, I want to > press on the desirability of this feature. > > The argument that you can work around it by not calling repr is certainly > true, but in practice, I don't think it's reasonable. Production error > reporting tools (like Sentry and New Relic) will call repr when reporting > on exceptions. > > I see this behavior as being analogous to a file object printing the first > 21 characters of a file, which it doesn't do (for good reason, I would > imagine): > > >>> f = open("foo.py") > >>> repr(f) > "<_io.TextIOWrapper name='foo.py' mode='r' encoding='UTF-8'>" > >>> > > I think we ought to reconsider the behavior of repr on QuerySets. I'm of > the opinion that we should scrap it completely. It could be replaced by > something that generates the SQL that would be executed (although that may > be tricky), or some kind of representation of the query filter. > > Any thoughts? > -- 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/ddce11f2-6971-484c-a9bf-28f65421488f%40googlegroups.com.
