Posted by jhedstrom on October 16, 2012 at 11:09pm
4 followers
| Project: | Drush |
| Component: | Core Commands |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
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.
Comments
#1
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.
#2
Seems 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'));?#3
Indeed, the logic in #2 is preferable--I had tunnel vision yesterday when I rolled that patch with the new hidden callback :)
#4
Feel free to commit #2
#5
Committed to 5 and 6.
#6
Automatically closed -- issue fixed for 2 weeks with no activity.