In #1497374: Switch from Field-based storage to Entity-based storage I noticed we're migrating deleted fields. Now that yched mentioned we already do that, I remember it from the field CMI patch, but it seems like extra work to me.

Rather than migrate the fields, we could require that Drupal 7 sites purge any remaining deleted fields before updating (i.e. run cron a few times usually), and have a warning in update requirements if any are found.

Comments

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented
Issue tags: +D8 upgrade path, +Field API, +Entity Field API

Tagging.

swentel’s picture

swentel commented

I understand the idea, but I'm wondering whether it's a good one.

It's perfectly possible to delete instance(s) manually, then disable (and uninstall) a module which provides the entity type that field instance is connected to. That field data will never be purged because field_read_instances() ignores instances of which the entity type is unknown. So running cron is not going to help, and the only way to inform the user is to print the machine name of the entity type which we need to be available. Other than that, we basically have nothing.

Another sweet example is the forum module. The 'taxonomy_forums' field is deleted in forum_uninstall. Even though field_purge_batch is called in the uninstall hook, there's no guarantee all data will be gone and next cron requests will not be able to clean that up.

I'm pretty sure we have dozens of D7 installations out there in the world with stale deleted fields data that is never cleaned up because of those two use cases.

IMO, this will make the upgrade path even more tedious then it already will be anyway. Not sure how to clean that up either though ...

catch’s picture

catch
he/him
Primary language English
commented

It's perfectly possible to delete instance(s) manually, then disable (and uninstall) a module which provides the entity type that field instance is connected to.

I didn't realise this, we can stop that from happening with the module/config uninstall issue, but can't fix it retrospectively.

If the fields are still in field config somewhere as deleted, and there's no way to purge them, could we maybe remove the field from config too at some point during the upgrade path? Then there's field tables left in the system, but no other record of the field at all - so worst case they get cleared out manually when they're spotted?

I'm also fine marking this won't fix if it makes things harder rather than easier.

yched’s picture

yched commented

The core uprgade is not an ideal time to decide whether a field is orphaned without its field type module - at least so far, with the current recommendation of "disable all contrib modules before upgrading core".

catch’s picture

catch
he/him
Primary language English
commented

That's not going to be an allowed workflow for 8.x once #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed is in - you'll be required to decide whether to enable or uninstall before upgrading. I'm assuming that patch is committed in any of these discussions..

yched’s picture

yched commented

Sure - still, what about a site upgrading to D8 without all its D7 contrib modules available at that time ?

roam2345’s picture

roam2345 commented
Issue summary: View changes

Does this issue even make sense any longer as i understand that the upgrade path from D7 -> D8 now requires a fresh install and use of the migrate module.. hence that mapping of these old tables you are speaking about would simply just not happen.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

quietone commented
Status: Active » Closed (outdated)

Yes, as lathan says, the migration system only migrates fields that are not deleted. There doesn't seem to be anything to do here. Closing as outdated.