Problem/Motivation

\Drupal\Core\Entity\Sql\SqlContentEntityStorage::countFieldData() should not need to know if it's querying a field stored in a shared or dedicated table.

Proposed resolution

After #2955442: Add a way to get all the tables in which a field is stored from TableMappingInterface lands, we'll have a way of getting the table name of a field regardless of whether it is a dedicated table or not and if it stores all revisions or just the default one.

So we should also be able to simplify countFieldData() and make it work only with information given by the table mapping interface, and not to rely on core's default implementation (DefaultTableMapping).

Remaining tasks

Discuss / review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

CommentFileSizeAuthor
#18 2960497-nr-bot.txt153 bytesneeds-review-queue-bot
#10 2960497-10-combined.patch8.86 KBamateescu
#10 2960497-10.patch5.23 KBamateescu
#8 2960497-8-combined.patch8.14 KBamateescu
#8 2960497-8.patch4.22 KBamateescu
#3 2960497-combined.patch28.35 KBamateescu
#3 2960497.patch8.64 KBamateescu

Comments

amateescu created an issue. See original summary.

amateescu’s picture

amateescu commented
Status: Active » Needs review
Parent issue: » #2274017: Make SqlContentEntityStorage table mapping agnostic

The main idea of this patch is that it allows the table mapping to be instantiated with only a subset of the field storage definitions of an entity type. In this case, we only need the table information for a single field, the one that we want to query and count its data.

There's still at least one failure in \Drupal\KernelTests\Core\Entity\EntityDefinitionUpdateTest::testBaseFieldDeleteWithExistingData() but I'd like to get some feedback on the general approach before spending more time on it :)

amateescu’s picture

amateescu commented
StatusFileSize
new 2960497.patch8.64 KB
new 2960497-combined.patch28.35 KB

Oops, forgot the patches.

Status: Needs review » Needs work

The last submitted patch, 3: 2960497-combined.patch, failed testing. View results

amateescu’s picture

amateescu commented

An interesting thing to note here is that the current code of the countFieldData() method, which makes a clear distinction between fields stored in dedicated vs. shared tables has caused a critical data loss bug in the past: #2559309: Logic error in SqlContentEntityStorage::countFieldData() drops dedicated field tables (again), with the only reason being that the original (also critical) issue forgot to take into account one of the if/else branches: #2527816: Logic error in SqlContentEntityStorage::countFieldData() attempts to drop `name` column

The code simplification proposed in this issue would have prevented at least the second bug.

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.

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.

amateescu’s picture

amateescu commented
Status: Needs work » Needs review
StatusFileSize
new 2960497-8.patch4.22 KB
new 2960497-8-combined.patch8.14 KB

New patch based on #2955442-40: Add a way to get all the tables in which a field is stored from TableMappingInterface.

Status: Needs review » Needs work

The last submitted patch, 8: 2960497-8-combined.patch, failed testing. View results

amateescu’s picture

amateescu commented
Status: Needs work » Needs review
StatusFileSize
new 2960497-10.patch5.23 KB
new 2960497-10-combined.patch8.86 KB

Nice, those fails are very easy to fix :)

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.

needs-review-queue-bot’s picture

needs-review-queue-bot commented
Status: Needs review » Needs work
StatusFileSize
new 2960497-nr-bot.txt153 bytes

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

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.