Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The 7.x-8.x upgrade path leaves several tables left over, {variables} is one but there'll be more. We should assume that by the time sites upgrade to Drupal 9, any useful information from those tables has been used, and drop them if they still exist.
List of tables to kill off:
Comments
Comment #0.0
catchUpdated issue summary.
Comment #1
xjmSo what should we do with the D7 Views tables? It's not core's responsibility to drop them, but on the other hand, there won't be a contrib module to drop them.
Comment #1.0
xjmUpdated issue summary.
Comment #2
catchNo idea... I don't think it particularly hurts if 9.x has an update function to drop 7.x views tables, so maybe we could just add it.
Also this entire issue is moot if #1052692: New import API for major version upgrades (was migrate module) happens.
Comment #3
dawehnerWhy shouldn't the d7d8 views upgrade module take care about that and remove the tables once it's ready with the processing?
Comment #4
Berdir@dawehner: For the same reason we don't remove the listed tables above in the 7.x -> 8.x in the core upgrade. People might e.g. have data that references these rows, so we give them a chance to upgrade it as well.
Comment #5
tim.plunkettThere could easily be a D8 contrib module that just clears out these tables, if someone was anxious about clearing them out.
Comment #6
dawehnerWell, in views you should have never referenced the table, because a view might have been stored in files. So does it make sense that we don't need it?
Comment #6.0
dawehnerfilter tables
Comment #6.1
xjmBlocks tables
Comment #6.2
xjmUpdated issue summary.
Comment #6.3
xjmUpdated issue summary.
Comment #7
xjmWell, I guess we'lll need to check if all the tables exist before we drop them, so there's probably no harm in adding the D7 Views tables to the list. It seems silly to create a whole contrib module just for that.
Comment #7.0
xjmUpdated issue summary.
Comment #7.1
xjmUpdated issue summary.
Comment #8
andypostUpdated summary with {menu_custom} #1814916: Convert menus into entities
Table {shortcut_set} was removed with #1497380: Convert shortcut sets to ConfigEntity
Tables {image_styles} and {image_effects} was removed with #1782244: Convert image styles $style array into ImageStyle (extends ConfigEntity)
Comment #8.0
andypostAdded {menu_custom} and sorted
Comment #9
larowlanAdded block_custom as per #1871772: Convert custom blocks to content entities
Comment #9.0
larowlanUpdated issue summary.
Comment #10
tstoeckler#512026: Move $form_state storage from cache to new state/key-value system dropped the {cache_form} table instead of adding it to this list. Since this does not store any actual content or config that is provided by modules, I think that was the right thing to do. Any module that stored its data there deserves a complete re-write anyway. Just noting here in case I misunderstood this issue and it's actually "Don't drop any tables in 8.x".
Comment #11
xjmRe #10: Yep, I think it's documented in the issue? If not that's my fault for asking in IRC and not commenting. But we don't need to preserve cache tables, because they do not contain permanent data.
Comment #11.0
xjm...placed {block_custom} beneath {block} where it alphabetically belongs ;)
Comment #12
xjmAdded Views' data tables to the list:
http://drupalcode.org/project/views_d8_upgrade.git/commit/b915d08
Comment #12.0
xjmUpdated issue summary.
Comment #13
swentel CreditAttribution: swentel commentedAdded field_config and field_config_instance after #1735118: Convert Field API to CMI got in.
Comment #13.0
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #13.1
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #13.2
swentel CreditAttribution: swentel commentedUpdated issue summary.
Comment #14
xjmNo longer relevant following Migrate in core (#2125717: Migrate in core: patch #1).
Comment #15
alexpottRemoving tag since it is not necessary.