My 5.x site uses block_cache module - so it's got a cache_block table. This makes update_fix_d6_requirements since there's no table_exists check in there.
I see two options:
1. Document this in upgrade instructions somewhere - either in the block_cache module, or changelog.txt or something that you'd need to uninstall first (like update status)
2. Drop the table if it exists then make it again.
The issue with 1. is if there's a 6.x version of block_cache - we can only lose everyone's cache settings. With 2. we'd have to know whether the block cache module in 6.x is going to use the core block_cache table and put it's own ui into it.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | why_core_needs_to_take_care_of_a_module_which_never_had_a_release.patch | 484 bytes | chx |
Comments
Comment #1
gábor hojtsyIf the block_cache module's cache_block table only contains cached blocks (ie. no settings to loose, but only reproducable cache data), then we are fine with dropping it IMHO and let block_cache module deal with any kind of update path going forward, if it ever gets released for Druapl 6. Moving to update system bug.
Comment #2
yched commentedIf this table does *not* only contain cached data, then it is probably a similar case as we had in D5 port of CCK, where core took the {node_type} table previously held by CCK.
What was done back then (system_update_1004) was to rename the table if it existed, then create the new core version of it. Then in its own update process, the conrib module grabs the old (renamed) table and does whatever it sees fit.
That should probably be coordinated with jjeff ?
Comment #3
catchSorry forgot to mention I cross-posted in the block_cache issue queue: http://drupal.org/node/200222
Just had a quick look at the cache_block table and it looks like it's just storing the cached data.
Comment #4
chx commentedComment #5
EnekoAlonso-1 commentedWhat if you have already updated to Drupal 6? I can drop the old cache_block table but where do I find the SQL for the new table? If I drop the table, update.php doesn't add the new one.
Comment #6
catchEnekoAlonso - if you install devel module, you could copy the PHP directly from the update function which creates cache_block and run it from the 'run PHP' window. Table creation in Drupal 6 is schema based, so there usually isn't a direct SQL query to be found.
Comment #7
rolodmonkey commentedI am going to assume that this is no longer an issue.
If anyone wants to disagree, you have two weeks before this is marked as closed :)
Comment #8
rolodmonkey commented