table "cache_features" does not exist

I've added a relation to my issue #2511876: Updating from 7.x-2.3 to 7.x-2.6 cache_features doesn't exist. I noticed that while just after creating, you had posted a similar issue :). 30 min difference.

Also happens with my MySQL installation:

WD php: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'edinburg_drupal_website.cache_features' doesn't exist: TRUNCATE {cache_features} ; Array                                                                                           [error]
(
)
 in cache_clear_all() (line 167 of /home/edinburg/i/sites/edinburghtwins.co.uk/includes/cache.inc).

Closing my topic to avoid duplication. @feqma in your case, have you tried placing the module without drush and running update.php ?

Just tested in a clean environment from 7.x-2.3 to 7.x-2.6.

Drush: fails due to cache clear that is seeing the newly introduced hook_schema() and is not yet known due to the update hook didn't run yet at that point.

Manually placing the folder: works, here are the steps:

1. Override old features folder with 7.x-2.6 version.
2. Update the database (drush updb or navigate to /update.php).
3. Clear your cache.

I'm not sure at this point if a fix could be written, because you need to introduce a schema in your update hook, but at the same time define it in hook_schema(). This last one causes an issue due to it's definition that is new.
Another option (but that will not be easy for most cases) uninstalling features and reinstalling might work.

I've ran into this bug too (2.5->2.6/mysql), and solved it by executing
drush ev "\$schema = drupal_get_schema_unprocessed('system', 'cache');db_create_table('cache_features', \$schema);"
before updating

Worked for me as well.

Updated severity and issue tags.
Maybe it's a good idea if the maintainers can put this workaround for Drush in the changelogs of the release?

So likely what is happening is cache is clearing before the update runs

What we can do is check that current schema is >= to the one that adds the table (schema version on new installs is set to latest update version, so this should work for new/old installs), in features_flush_caches

What exact steps did you use to get this error? A simple "drush dl" should not be clearing caches. You should ALWAYS run updates before clearing caches. So I'm not sure this is really "Major", it just means using normal best practices for updating a module.

It happens on 'drush up'. At that point drush will download the newer version, clear the caches and run the update hooks. The problem is that at the clear caches, it's rolling back due to the error.

I've increased this issue to Major because I believe many people will update through drush. That being said, automated actions or tests in for examples CI systems will fail at this point.

Please try out the (totally untested, hopefully no parse error) patch above!

Confirm that error doesn't occur and that features cache is flushed later

@hefox: will try to test it this weekend.

hefox - I was having this problem following the latest OpenAtrium upgrade (7.x-2.42) and patch #13 saved the day.

The patch applied cleanly, but I continued having problems running drush updb and doing drush cc all until I did a drush registry rebuild, cleared cache tables in the database and also ran drush fra -y - basically mpotter's advice on another issue (thanks!).

@hefox: this appears to do the trick (simulated in a dummy VM with Drush 5.x). I've also noticed that with a higher major version of Drush, this doesn't appear to be an issue anymore. So the issue of 'cache clear' before 'updb' is probably changed from Drush 5.x -> 6.x.

• Decreased priority now that I know this only occurs in older versions of Drush.
• Added 'drush 5.x' as issue tag.

Committed this to a30f719 since it makes sense to check first. This is definitely an issue because all existing distributions on drupal.org are stuck using Drush 5 for now. Thanks for testing this patch!

#7 worked for me, many thanks

While the patch at #13 seems to work, the notion that one shouldn't do a cc all until the end is unrealistic. The problem is not a manual drush cc all, it's that many contrib or custom modules, in the course of running their own update hooks, may clear all caches programmatically, causing the hook to throw the PDO exception and fail. What's really needed is a way to add weighting to update hooks, forcing particular ones to run before others. One can do this, kinda-sorta, with hook_update_dependencies(), but in order to use that you really have to have complete control over all the system as a whole and know what updates you need to declare dependent on your own update, and afaik there's no way to know that in advance.

closed. but still issues with this.

- i upgraded from 1.x to 2.6 and got this error on update
- i upgraded to latest -dev as per this post and trying to run update the issue persists.
- i disabled (but no uninstalled Features) and re-enabled - module save now causes this error

any thoughts on what is required to get Features working again? do i need to uninstall Features? do i need to go back to a db backup before trying 2.6?

always more than 1 way to skin a kitten... i simply grabbed that table from another site which was using 2.6 and all is well.

still think issues with this but will put back as closed.

#7 worked for me, thanks!

#7 worked for me, thanks!

tested patch, also worked for me!