Active development on the entity storage layer has mostly stalled since 2015, and the number of subtle bugs and @todos in code are clearly showing the amount technical debt that we're dealing with.

The end goal of this plan is to allow alternative (non-)SQL storage and table layout implementations in contrib without forcing them to re-implement all the storage / entity query / views integration code. I think we can achieve this by removing the notions (and core usages) of entity base / data / revision / revision_data / dedicated tables, and replace them with the general notion that "everything is a field table".

Step 1: Finalize the Table Mapping API

Step 2: Update core to use the new API

After completing the table mapping API, we should be able to start on cleaning up all the places that still use D7-style logic when dealing with the entity storage as well as long standing @todo's and bug reports.

Specifically, we should be able to:

And all that while also having the abilty to swap the table mapping to an entirely custom implementation, for example one that uses a single table to store all the revision/translation/multi-value field data, like the Entity Storage JSON module :)

Comments

amateescu created an issue. See original summary.

amateescu’s picture

amateescu commented
Issue summary: View changes

The first blocker issue is in! #2916018: Allow the table mapping to be initialized from outside the storage

Next on the priority list is #2955442: Add a way to get all the tables in which a field is stored from TableMappingInterface.

And here's the kind of cleanup that is enabled by the new capabilities of the table mapping API: #2960497: Simplify SqlContentEntityStorage::countFieldData()

amateescu’s picture

amateescu commented
Issue summary: View changes

Updating the IS with some progress!

amateescu’s picture

amateescu commented
Issue summary: View changes

Added #2984782: Add an API for converting entity type schemas to (non-)revisionable/(non-)translatable, with or without data to the list.

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

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.

plach’s picture

plach
he/him
Primary language Italian
Location Venezia
commented
Related issues: +#2401107: Consider generalizing DefaultTableMapping

Related issue: #2401107: Consider generalizing DefaultTableMapping

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

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.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.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.