SQL queries should use cache key which gets invalidated when something relevant changes

Bug #498387 reported by Daniel Hahler
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
b2evolution
Triaged
Wishlist
Unassigned

Bug Description

The following query result should get cached, unless tag associations get changed.

For example by having a cache key on the blog (which is NULL in this case), status and anything else relevant.

When anything part of this key gets changed, the cached result should get invalidated and fetched/calculated anew on the next access.

AFAIK this is partly implemented, but probably not for this query (and others which could benefit from this).

Caching widget output (it's the tag widget in this case) is a good way to "work around" this, but like page level caching it's the granularity that may get missed.
I agree however that when the tag widget would cache it's output based on the same keys this query would use, this would be OK with this particular case.

Query #100: Get tags
SELECT LOWER(tag_name) AS tag_name, post_datestart, COUNT(DISTINCT itag_itm_ID) AS tag_count
FROM evo_items__tag INNER JOIN evo_items__itemtag ON itag_tag_ID = tag_ID INNER JOIN evo_items__item ON itag_itm_ID = post_ID
WHERE 1
  AND post_status = 'published'
  AND post_datestart < '2009-12-19 00:13'
GROUP BY tag_name
ORDER BY tag_count DESC
LIMIT 50

Daniel Hahler (blueyed)
Changed in b2evolution:
status: New → Triaged
importance: Undecided → Wishlist
tags: added: cache performance
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.