Query Builder Bug revisited

Hi.

Ruslan Zakirov wrote:

As I know that happens since 3.0.x and as I remeber that somehow
related to the code that build next/prev links. I thought this was
fixed in recent versions. Looks like we need to check that again.

Further to this:
I have a fresh install of 3.4.5.
When I do a query in the query builder for

Created > ‘2006-01-01’

I get 51000 tickets.
Now, if I go to load a ticket, it takes a considerably long time for the ticket to load.
When I’ve loaded the ticket and go back to the listing, click on another ticket, the same thing again. It seems that regardless of the ticket/transactions/attachments length, the actual ticket takes just as long to load as the previous ticket.
This is consistent each time the above is repeated.

The length seems to depend on the number of tickets returned by the query.

Why is that?

Kr.
LukeOn 3/23/06, Luke Vanderfluit lvanderf@internode.com.au wrote:

Hi.

Ruslan Zakirov wrote:
RT version?

3.4.5

On 3/23/06, Luke Vanderfluit lvanderf@internode.com.au wrote:

Hi.

I’ve found what appears to be a bug in the query builder.
When I build a query that needs to do search of contents of tickets.
Say, for example, I search all tickets with the following query:

Created > ‘2006-01-01’ AND Content LIKE ‘foo’

that query could take a very long time to complete, which is normal (not
acceptable but OK (-:slight_smile:

After the query has completed I go to delete the “AND Content LIKE
’foo’” phrase and the query seems to run again!

I’m looking at the mysql processes that are triggered by this behaviour.
It seems like the query builder might be using up resources that it
shouldn’t need to.

Can anyone confirm this behaviour? That changing the composition of the
query actually causes the query to run again?

Luke