Currently upgrading a site from D6 to D7.

Other than a few CCK-related modules installed and upgraded, Token is the first module I'm upgrading in this process.

After copying in the latest stable Token release (rc1), then running "drush en token," the following error is spat out:

WD php: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'database_name.cache_token' [error]
doesn't exist: TRUNCATE {cache_token} ; Array
(
)
in cache_clear_all() (line 176 of /path/to/drupal/includes/cache.inc).
Cannot modify header information - headers already sent by (output started at                                       [warning]
/path/to/drush/includes/drush.inc:596) bootstrap.inc:1239
PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'database_name.cache_token' doesn't exist: TRUNCATE {cache_token} ; Array
(
)
in cache_clear_all() (line 176 of /path/to/drupal/includes/cache.inc).
Drush command terminated abnormally due to an unrecoverable error.                                                  [error]

Looking through, I see that the cache_tokens table doesn't exist until it's created in a database update.

Standard practice for upgrades says that you should enable the module before performing updates, so I'm guessing there's something wrong in Token code that assumes the cache_token table exists during module enablement.

Files: 
CommentFileSizeAuthor
#4 1512934-check-if-cache-token-table-exists.patch834 bytesDave Reid
PASSED: [[SimpleTest]]: [MySQL] 342 pass(es).
[ View ]
#2 token-d6_d7_cache_token_missing-1512934-2.patch612 bytesiamEAP
PASSED: [[SimpleTest]]: [MySQL] 307 pass(es).
[ View ]

Comments

Dave Reid’s picture

Status:Active» Postponed (maintainer needs more info)

The cache_token is described and provided in token_schema() which should automatically be created when you first install the module (anything in hook_schema() is automatically created via module_enable()). However, if this site was an upgrade or used to have the Token module enabled at some point, you'll need to ensure to run the update.php script so that the cache_token table can be created.

iamEAP’s picture

Title:Table "token_cache" missing when enabling module» When upgrading from 6.x, token_cache isn't created, causing error on enablement
Status:Postponed (maintainer needs more info)» Needs review
StatusFileSize
new612 bytes
PASSED: [[SimpleTest]]: [MySQL] 307 pass(es).
[ View ]

Tested to see if it was a problem with drush, and it isn't. If I enable Token through the GUI, I get the following:

Error: The website encountered an unexpected error. Please try again later.

Looks like on module enablement, both drush and core ultimately call drupal_flush_all_caches().

On new installs, this doesn't matter because, as you noted, everything in token_schema gets created during the install process.

For those upgrading from the latest 6.x version, schema_version is set to 1 and, as a result, the usual install stuff (including creation of hook_schema tables) never happens. Thus, Drupal tries to truncate a table that doesn't exist yet.

My proposed solution is to implement a hook_enable that runs the 7000 update if appropriate.

Dave Reid’s picture

Version:7.x-1.0-rc1» 7.x-1.x-dev

If the schema version is set to 1 when you run the upgrade, then token_update_7000() should absolutely be running. I wonder if another update runs before our module and then runs against a table that will be created, but isn't yet since the updates aren't finished running yet.

Dave Reid’s picture

StatusFileSize
new834 bytes
PASSED: [[SimpleTest]]: [MySQL] 342 pass(es).
[ View ]

Please test this patch out, which prevents cache_clear_all() from being called on the cache_token table until it exists.

iamEAP’s picture

module_enable() only runs drupal_install_schema() if drupal_get_installed_schema_version() returns SCHEMA_UNINSTALLED (-1).

Dave Reid’s picture

Aha! I think this is officially a duplicate of a core bug: #1477932: Allow cache() and cache_clear_all() to fail gracefully if a database cache bin does not exist but we can add a workaround with the patch in #4 for now.

Dave Reid’s picture

I'm not talking about running token_schema(), on an update, token_update_7000() should eventually run in the update process which creates the cache_token table.

iamEAP’s picture

Definitely a dupe.

Both #2 and #4 are viable workarounds. Personally, I like #2 because the only time it has an effect is on module enablement (while #4 gets touched on a number of cache clears into the future).

But honestly, whatever gets the job done.

iamEAP’s picture

Status:Needs review» Reviewed & tested by the community

Reflecting discussion in the core thread, let's go with #4.

Dave Reid’s picture

Status:Reviewed & tested by the community» Fixed

Status:Fixed» Closed (fixed)

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