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`:

<?php
 
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.

Files: 

Comments

Status:Active» Needs review
StatusFileSize
new1.38 KB

The 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.

Seems like a really good idea; however, instead of drush_invoke_process('@self', 'updatedb-cache-clear');, wouldn't it be better to just use drush_invoke_process('@self', 'cache-clear', array('all'));?

Status:Needs review» Needs work

Indeed, the logic in #2 is preferable--I had tunnel vision yesterday when I rolled that patch with the new hidden callback :)

Status:Needs work» Reviewed & tested by the community

Feel free to commit #2

Status:Reviewed & tested by the community» Fixed

Committed to 5 and 6.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.