The following steps lead to a situation where drush cc all would fail.

  1. Build a site, with fields and stuff. Especially one or some fields for the user entity.
  2. Install an alternative cache plugin, e.g. mongodb.
  3. Change the site configuration. E.g. remove one of the fields on user entity.
  4. Disable the alternative cache plugin, switch back to database cache.

Now the database cache contains really old data (or this is how I imagine it), still referencing fields that have long been deleted.

On drush cc all, drush first wants to bootstrap Drupal. Doing this, it also tries to load a user account for login. This lets it use cached data for user fields.

I get a crash with mysql exception from field_sql_storage_field_storage_load(), because it tries to load non-existing fields.

I suppose this is just one example for a site being broked due to really old cache data, after switching the cache plugin.

How can one recover from this situation?

  • 1
    Manually truncate the cache_ tables in the database. – Ruben Beekman Jan 25 '17 at 16:16
  • But how do I do this easily all at once? An ugly shell command? – donquixote Jan 25 '17 at 16:24
  • I did run a "show all tables" and then decided that no, I am not really interested crafting a sophisticated command that only truncates the cache tables while leaving the others untouched.. I prefer to only use commands that I immediately understand when looking at them. – donquixote Jan 25 '17 at 16:32
  • A quicker way would be use a sql client like HeidiSQL or SequelPro, select all the cache_ tables in the list of tables in the database, and click Truncate. Takes a few seconds. – Kevin Jan 25 '17 at 16:35
  • 1
    Here is also a SQL statement that will do it. stackoverflow.com/a/1575435/295112 – Kevin Jan 25 '17 at 16:36

For me the following hack worked:

  1. Edit includes/cache.inc. Let function cache_get() return FALSE.
  2. Run drush cc all.
  3. Revert the hack in includes/cache.inc.

I am not saying this is the best solution. But it did work for me, on a dev system. I am not sure I would recommend this on a production system.

Here is the hack:

 function cache_get($cid, $bin = 'cache') {
+  return FALSE;
+  # return _cache_get_object($bin)->get($cid);
-  return _cache_get_object($bin)->get($cid);
  • This is rather clever. I also would not consider this hacking core. Working out of a test branch, and editing core for quick workaround, debug, etc, is OK. Just don't commit the changes back to what you deploy live. – mpdonadio Jan 25 '17 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.