Re: Optimization for get_search_results() in admin

I remain +1 to the change I can see how we could claim this is "an implementation detail". But I think we should also be sympathetic to the idea that this change may break many workflows If folks really want the old behavior they can customize and then impose > some limits to prevent excessive jo

Re: Optimization for get_search_results() in admin

Hi list, I came to suggest a resolution for the above: the potential for impossible (or resource-gobbling) queries in admin changelist searches. (Ticket ) Several folks have proposed the same solution: AND’ing Q objects together rather than chain

Re: Optimization for get_search_results() in admin

Hi, I've also seen this behaviour before at YPlan, we sometimes got the "mysql can't join more than 61 tables" error or had the database slow to a crawl. Some of the admin classes required custom get_search_results functions to fix this. I have only skimmed the old tickets and PR's but I think th

Re: Optimization for get_search_results() in admin

I don't know whether anyone will see this, as it's my first time posting here, but I have to second this. This problem brought down our site yesterday when an unsuspecting admin user tried a 3-word search in an admin that had several search fields involving joins. The result was that the number

Optimization for get_search_results() in admin

Hello, I would like to open a discussion on the change I have proposed with pull request #7277 . To bring the discussion here, the problem with current implementation of get_search_results() is that, when search fields include fields through reverse