cache_block table already exists if you use block_cache module [#200221]

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
#4

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Gábor Hojtsy

he/him

Hungarian

Hungary

CreditAttribution: Gábor Hojtsy commented 12 December 2007 at 14:26

Component:

documentation

» update system

If 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 CreditAttribution: yched commented 12 December 2007 at 14:47

If 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

catch

he/him

English

CreditAttribution: catch commented 12 December 2007 at 15:22

Sorry 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 CreditAttribution: chx commented 17 December 2007 at 21:19

Status:

Active

» Needs review

File	Size
why_core_needs_to_take_care_of_a_module_which_never_had_a_release.patch	484 bytes

Comment #5

EnekoAlonso-1 CreditAttribution: EnekoAlonso-1 commented 28 February 2009 at 07:24

What 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

catch

he/him

English

CreditAttribution: catch commented 28 February 2009 at 13:19

EnekoAlonso - 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.