Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The patch introduced in #1421844: views_fetch_data() cache item can reach over 10mb in size has a bug that produces a full cache rebuilds when you ask for an specific table cache data for which views cannot get any data.
In a current project this bug is causing that saving some big views takes +4 minutes.
I think it is safe to assume that if we didn't get cache data for a table at the first rebuild we are not going to get it in the next.
Comment | File | Size | Author |
---|---|---|---|
#1 | 1889198-views-cache-rebuild.patch | 612 bytes | Pedro Lozano |
Comments
Comment #1
Pedro Lozano CreditAttribution: Pedro Lozano commentedThis patch solves the problem and I think it doesn't cause any side effects.
Comment #2
dawehnerThis is looking pretty good, and similiar to Drupal 8 :)
Comment #3
Pedro Lozano CreditAttribution: Pedro Lozano commentedPosted a patch for D8 at #1889810: Performance, unnecessary views cache rebuilds.
Comment #4
andrewbelcher CreditAttribution: andrewbelcher commentedI can confirm that this solved the problem. Attempting to clear caches was timing out for me, and even drush was taking more than 10 minutes just for a
cc menu
. With this patch it took seconds. This would be a really helpful patch to have committed!Comment #5
dawehnerMy question is: Why does something asks for a views table which does not exist?
One example could be a view in the system, for a table that does not exist, feel somehow wrong, but I agree we should fix that.
Comment #6
andrewbelcher CreditAttribution: andrewbelcher commentedOur example was a module that had been disabled. But there were still views in the database built on an entity created by the disabled module...
It seems odd to be tracking
$fully_loaded
but not always respecting it...Comment #7
Pedro Lozano CreditAttribution: Pedro Lozano commentedIn my case, it was some old broken views that were using fields that no longer existed. For each broken field, two views data cache rebuilds were performed.
Comment #8
andypost+1 to commit, in my case this was caused by broken view (used fields that was deleted)
Comment #9
dawehnerAwesome, thanks for providing a patch and testing it!
Committed and pushed