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:

Table Issue
{authmap} #817118: Remove {authmap} and migrate OpenID entries to their own table
{block} #1535868: Convert all blocks into plugins
{block_custom} #1871772: Convert custom blocks to content entities
{block_language} #1535868: Convert all blocks into plugins
{block_node_type} #1887692: Clean up unused {block_node_type} table and references
{block_role} #1535868: Convert all blocks into plugins
{date_format_type} #1571632: Convert regional settings to configuration system
{date_formats} #1571632: Convert regional settings to configuration system
{date_locale} #1571632: Convert regional settings to configuration system
{field_config} #1735118: Convert Field API to CMI
{field_config_instance} #1735118: Convert Field API to CMI
{filter} #1779026: Convert Text Formats to Configuration System
{filter} #1779026: Convert Text Formats to Configuration System
{image_styles} #1464554: Upgrade path for image style configuration
#1980058: image_update_8001() should not drop tables
{image_effects} #1464554: Upgrade path for image style configuration
#1980058: image_update_8001() should not drop tables
{menu_custom} #1814916: Convert menus into entities
{taxonomy_vocabulary} #1552396: Convert vocabularies into configuration
{views_view} #1805996: [META] Views in Drupal Core
{views_display} #1805996: [META] Views in Drupal Core

Comments

catch’s picture

catch
he/him
Primary language English
commented
Issue summary: View changes

Updated issue summary.

xjm’s picture

xjm
she/her
Primary language English
commented

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

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Updated issue summary.

catch’s picture

catch
he/him
Primary language English
commented

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

dawehner’s picture

dawehner
Primary language German
commented

Why shouldn't the d7d8 views upgrade module take care about that and remove the tables once it's ready with the processing?

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

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

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

There could easily be a D8 contrib module that just clears out these tables, if someone was anxious about clearing them out.

dawehner’s picture

dawehner
Primary language German
commented

Well, 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?

dawehner’s picture

dawehner
Primary language German
commented
Issue summary: View changes

filter tables

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Blocks tables

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Updated issue summary.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Updated issue summary.

xjm’s picture

xjm
she/her
Primary language English
commented

Well, 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.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Updated issue summary.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Updated issue summary.

andypost’s picture

andypost
he/him
Primary language Russian
commented

Updated 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)

andypost’s picture

andypost
he/him
Primary language Russian
commented
Issue summary: View changes

Added {menu_custom} and sorted

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

Added block_custom as per #1871772: Convert custom blocks to content entities

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Issue summary: View changes

Updated issue summary.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented

#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".

xjm’s picture

xjm
she/her
Primary language English
commented

Re #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.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

...placed {block_custom} beneath {block} where it alphabetically belongs ;)

xjm’s picture

xjm
she/her
Primary language English
commented

Added Views' data tables to the list:
http://drupalcode.org/project/views_d8_upgrade.git/commit/b915d08

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes

Updated issue summary.

swentel’s picture

swentel commented

Added field_config and field_config_instance after #1735118: Convert Field API to CMI got in.

swentel’s picture

swentel commented
Issue summary: View changes

Updated issue summary.

swentel’s picture

swentel commented
Issue summary: View changes

Updated issue summary.

swentel’s picture

swentel commented
Issue summary: View changes

Updated issue summary.

xjm’s picture

xjm
she/her
Primary language English
commented
Issue summary: View changes
Status: Active » Closed (duplicate)
Related issues: +#2125717: Migrate in core: patch #1

No longer relevant following Migrate in core (#2125717: Migrate in core: patch #1).

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented
Issue tags: -D9 upgrade path

Removing tag since it is not necessary.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.