I moved a current sql backup from production to dev machine.
When looking at project nodes the releases table is not refreshed. I cleared core cache and views cache several times. Nothing changed. The content still has links to the production site and has not rebuild the incorrect links in the table.
After some digging I TRUNCATE TABLE cache_project_release_download_table;
. After reloading project nodes the cache was rebuild.
And now one more issue came in my mind. The Notes
and Edit
links disappeared from the releases table. Compared to the live site and found these Links are still there, but I guess they should no longer shown. They are shown for both anonymous and logged in users - what makes not much sense if it comes to Edit.
This means the cache need to be rebuild. There is no easy way to do this or I have not found any. These cache_project_release_download_table
contains HTML code in a blob field that is never updated or only if you edit some stuff what nobody does.
Comments
Comment #2
hass CreditAttribution: hass commentedComment #3
drummThe notes and edit links were removed with #2262073: Remove edit link from download table
Comment #4
drummFor clearing the cache - I've been feeding
cache_clear_all('*', 'cache_project_release_download_table', TRUE);
to drush. A UI would be nice to add.Not having it clear on cache clear all helps soften cache stampeding.
Comment #5
hass CreditAttribution: hass commentedThanks for clarification that I cleared it correctly.
But why should the cache clearing use a different logic than page/block and other caches? I always hate that Views has it's own cache-clear... if every module implements it's own cache clear mechanism we end up in a real mess. I'm not a fan of this.
Comment #6
dww@hass: Because of what drumm said -- if *every* cache clears simultaneously, then performance life sucks tremendously immediately after a cache clear, especially on a site at the scale of Drupal.org.
That said, yes:
A) Bug: this cache probably needs to be invalidated programmatically more often than it is. There are conditions that should trigger an invalidation which apparently aren't happening as expected.
B) Feature: sure, we could add a UI to clear this cache, perhaps per-project, and/or site-wide.
Comment #7
hass CreditAttribution: hass commentedSorry, I should have not written this as question. It was clear to me that clearing all caches is a short performance penalty for large sites like d.o.
I may better asked how d.o manages this cache-clear performance penalty for other pages. It looks not right to me that every module try to build something special for caching. It's better to integrate with standard core api's and reuse existing core caching logics.
Highly interrested how the performance issues are solved for other cache tables on d.o. That caching issue cannot be a problem of project module only.
Comment #8
drummWe do use standard core APIs. Clearing “all” caches does not need to affect every cache if a specific cache type has special requirements.