Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
With modules such as ctools making heavy use of static caching, the result of this is that staticly cached variables are potentially horribly outdated by the time this code runs at the end of `drush updatedb`:
if (drush_drupal_major_version() <= 6) {
// Clear all caches. We just performed major surgery.
drush_drupal_cache_clear_all();
}
this is even more pronounced when modules are enabled during update hooks. Further more, no matter what static caches are manually cleared during update, this has no effect on the calling process which then clears caches with the old static still in place.
Comment | File | Size | Author |
---|---|---|---|
#1 | drush-updatedb-cache-clear-1814818-01.patch | 1.38 KB | jhedstrom |
Comments
Comment #1
jhedstromThe attached patch resolves the issue I was seeing with static variables.
To duplicate, install a basic D6 site, enable features and create and enable a feature via the features module (dump the db). Now, download facetapi and apachesolr. Enable these modules, and enable some facets. Export those facets to the feature, and add an update hook that enables facetapi, apachesolr, and positions some facet blocks. No matter what crazy cache clearing is attempted in the update hook, the blocks go away when the final cache clear happens in updatedb. With this patch, the blocks persist.
Comment #2
greg.1.anderson CreditAttribution: greg.1.anderson commentedSeems like a really good idea; however, instead of
drush_invoke_process('@self', 'updatedb-cache-clear');
, wouldn't it be better to just usedrush_invoke_process('@self', 'cache-clear', array('all'));
?Comment #3
jhedstromIndeed, the logic in #2 is preferable--I had tunnel vision yesterday when I rolled that patch with the new hidden callback :)
Comment #4
moshe weitzman CreditAttribution: moshe weitzman commentedFeel free to commit #2
Comment #5
jhedstromCommitted to 5 and 6.