Opened 14 years ago
Closed 14 years ago
#15543 closed defect (bug) (fixed)
_get_last_post_time() uses the incorrect cache key
Reported by: | mdawaffe | Owned by: | scribu |
---|---|---|---|
Milestone: | 3.1 | Priority: | high |
Severity: | major | Version: | |
Component: | Cache API | Keywords: | |
Focuses: | Cc: |
Description
[15838] sets the cache key to
"lastpost{$field}:" . get_current_blog_id() . ":$timezone:" . md5( serialize( $post_types ) )
but that key is never invalidated. The invalidation is meant to be handled by _transition_post_status()
.
There's no need to explicitly include the blog_id in a cache key.
If the data needs to be cached by some dynamic variable ($post_types, in this case), there are a few options.
- The invalidation needs to be a lot smarter (hard).
- The cached data needs to be an array (
$data[ serialize( ... ) ] = $date
) so that it can be invalidated all at once (bad - leads to race conditions). - The data should only be cached for one single page load (
wp_cache_add_non_persistent_groups()
). - Something else?
Change History (8)
#1
@
14 years ago
- Component changed from General to Cache
- Milestone changed from Awaiting Review to 3.1
- Priority changed from normal to high
- Severity changed from normal to major
#3
follow-up:
↓ 6
@
14 years ago
A compromise would be to use a single cache key for all post types. That will still probably take care of the original problem.
#6
in reply to:
↑ 3
@
14 years ago
Replying to scribu:
Is there a way to invalidate the entire 'timeinfo' group?
No. Memcache (and most wp_cache implementations) cannot do this.
There's a way around this, but it's tricky. You keep track of an incrementor, $i, in the cache and then do cache operations on the group "timeinfo-$i". To "invalidate" the group, you increment $i using wp_cache_incr().
Replying to scribu:
A compromise would be to use a single cache key for all post types. That will still probably take care of the original problem.
That would work.
Is there a way to invalidate the entire 'timeinfo' group?