Closed (fixed)
Project:
Token
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
3 Apr 2012 at 00:24 UTC
Updated:
20 Apr 2012 at 00:51 UTC
Jump to comment: Most recent file
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.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1512934-check-if-cache-token-table-exists.patch | 834 bytes | dave reid |
| #2 | token-d6_d7_cache_token_missing-1512934-2.patch | 612 bytes | iamEAP |
Comments
Comment #1
dave reidThe 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.
Comment #2
iamEAP commentedTested to see if it was a problem with drush, and it isn't. If I enable Token through the GUI, I get the following:
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.
Comment #3
dave reidIf 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.
Comment #4
dave reidPlease test this patch out, which prevents cache_clear_all() from being called on the cache_token table until it exists.
Comment #5
iamEAP commentedmodule_enable() only runs drupal_install_schema() if drupal_get_installed_schema_version() returns SCHEMA_UNINSTALLED (-1).
Comment #6
dave reidAha! 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.
Comment #7
dave reidI'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.
Comment #8
iamEAP commentedDefinitely 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.
Comment #9
iamEAP commentedReflecting discussion in the core thread, let's go with #4.
Comment #10
dave reidCommitted #4 to 7.x-1.x: http://drupalcode.org/project/token.git/commit/7afd95c