Opened 20 months ago

Last modified 20 months ago

#18778 new enhancement

Add filters to transform_query() to allow caching of queries created by this function.

Reported by: tott Owned by:
Priority: normal Milestone: Awaiting Review
Component: Taxonomy Version:
Severity: normal Keywords: has-patch 2nd-opinion
Cc: tott@…

Description

transform_query() works great on regular datasets, but if you run this on a large set of data it can get very expensive. adding some filters in here that could allow these queries to be cached would be benefitial.

Attachments (1)

transform_query_filters.diff (1.3 KB) - added by tott 20 months ago.

Download all attachments as: .zip

Change History (9)

  • Keywords has-patch added
  • Keywords close added

transform_query() is a private, intermediary step. I don't think it should be made public through a filter.

Why not cache the final result?

The problem is that even with something like advanced-caching enabled these queries are fired in order to built the final query. So even if you would add caching on the final query it would still execute these queries on the way to build the final one. At least as far as I experienced this. Where would you hook into to avoid this queries?

  • Keywords 2nd-opinion added; close removed

I was thinking of the case where you can prevent the whole call to WP_Query by caching the list of posts. Not sure how practical that would be for the main query.

Last edited 20 months ago by scribu (previous) (diff)

PS: 'transform_query_' is too generic. Maybe 'transform_terms_query_'.

comment:6 follow-up: ↓ 7   westi20 months ago

The filter names here don't make sense to me.

If the idea (as it seems it is) is to suppress the code from running the queries that I would expect "suppress" to be in the name of the filter.

However, I'm not sure yet this is even the right place to be doing the suppression - maybe we should be doing it where we call the function instead?

comment:7 in reply to: ↑ 6   tott20 months ago

It is not really about suppressing the call. It's more about simply filling $terms with the necessary values without a db query. This would be the place where plugins like advanced-caching could jump in to avoid the query.

I will see if I can wrap up a standalone example to point out the issue.

Note: See TracTickets for help on using tickets.