Line 399 of views/src/ViewsConfigUpdater is
$table_info = $this->getMultivalueBaseFieldUpdateTableInfo();

getMultivalueBaseFieldUpdateTableInfo() in turn calls EntityFieldManager->getBaseFieldDefinitions()

EntityFieldManager->getBaseFieldDefinitions() throws a "Getting the base fields is not supported for entity type" exception when it gets an entity that isn't fieldable, like config entities. This causes problems when trying to upgrade a module that uses config entities and has a dependency on Views from Drupal 8 to Drupal 9.

processMultivalueBaseFieldHandler() should be modified to wrap getMultivalueBaseFieldUpdateTableInfo() in a try/catch.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sunset_bill created an issue. See original summary.

sunset_bill’s picture

Issue summary: View changes
FileSize
691 bytes
sunset_bill’s picture

Title: ViewsConfigUpdater::processMultivalueBaseFieldHandler() throws exception for config entities » "Getting the base fields is not supported for entity type" exception in ViewsConfigUpdater
Version: 8.9.x-dev » 9.1.x-dev
Issue summary: View changes
sunset_bill’s picture

sunset_bill’s picture

Issue summary: View changes
Lendude’s picture

Issue tags: -Upgrade path. +Needs steps to reproduce

an entity that isn't fieldable, like config entities

What would be the steps to reproduce here? Views doesn't support config entities and all content entities presumably implement ContentEntityInterface which in turn implements FieldableEntityInterface.

Is there an example module somewhere that could cause this?

sunset_bill’s picture

This is happening in a proprietary custom module, so no code available. We did have to do some hacking to get our config entity to work with Views, all so we could do some bulk operations. We've got

  • a views query plugin
  • a ViewsData class that implements EntityViewsDataInterface
  • a views.view.ENTITY_TYPE.yml file that includes fields
  • and, of course, the ENTITY_TYPE.schema.yml

I've just now gone through all of those and made sure they all agree on the fields, hoping you'd pointed me to the error of my ways, but I still get that exception without the try/catch around getMultivalueBaseFieldUpdateTableInfo().

sunset_bill’s picture

sunset_bill’s picture

sunset_bill’s picture

I should add that this is a module that's been in use on enterprise-level sites since early 8.x. This issue only cropped up in 8.9.

sunset_bill’s picture

Looking more into this, I really do believe this should be considered a legitimate bug and not an edge case. While Views might assume it's dealing with content entities, things have worked so far because up until 8.7 EntityFieldManager->getBaseFieldDefinitions() returned an empty array if no fields were found. As of 8.8 it throws an exception, and Views code should handle that exception.

Lendude’s picture

Status: Active » Needs work
Issue tags: +D8 upgrade path, +8.9.0 update

Closed #3152747: [error] Getting the base fields is not supported for entity type *, I like the fix in that issue a little better. Copying tags over from that issue.

Still have doubts about actively supporting config entities in Views though, but adding a sanity check here seems like a good step. We do need a test for it though.

Lendude credited facine.

Lendude’s picture

Version: 9.1.x-dev » 8.9.x-dev
Status: Needs work » Needs review
Issue tags: -Needs steps to reproduce
FileSize
3.67 KB
4.83 KB

Here we go with a test and the fix from the other issue. Credited @facine for that. No interdiff because the fix changed.

The last submitted patch, 14: 3143316-13-TEST_ONLY.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Status: Needs review » Needs work

The last submitted patch, 14: 3143316-13.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Lal_’s picture

fixing coding standard issue

Lal_’s picture

Status: Needs work » Needs review
Lendude’s picture

Lets see if this clear up the test fail

@Lal_ if you are going to do those types of fixes, do them on patches that are done, not the ones that still have failed tests, just leave a review and check that they are fixed on the next iteration. And if you still want to do this, leave an interdiff and fix all of the CS violations because now it just looks like a credit grab.

Edit: No idea where it cached my version of the -17 patch, but apparently reloading the page doesn't clear my uploads ¯\_(ツ)_/¯, ignore my -17 and take -19

The last submitted patch, , failed testing. View results

daffie’s picture

Reuploading the patch that should be committed.

The added fix looks good to me and fixes the problem from the IS.
The added testing also looks good to me.
When I run the test with the full patch the test passes.
When I run the test with only the added test and not the fix the test fails.
For me it is RTBC.

xjm’s picture

Priority: Normal » Critical

Issues and regressions with the data upgrade path are generally critical, so bumping the priority accordingly. Thanks!

xjm’s picture

Thanks for triaging this.

#21 has fails like

Testing Drupal\Tests\filter\Functional\FilterFormatAccessTest
EEE                                                                 3 / 3 (100%)

Time: 3.16 seconds, Memory: 4.00 MB

There were 3 errors:

1) Drupal\Tests\filter\Functional\FilterFormatAccessTest::testFormatPermissions
Drupal\Core\Extension\InfoParserException: The 'core_version_requirement' constraint (9.1.0-dev) requires the 'core' key not be set in core/modules/views/tests/modules/views_config_entity_test/views_config_entity_test.info.yml

The 8.9.x fail has been showing up in HEAD on certain environments, but (weirdly) not others. Going to retest against a couple more environments.

xjm’s picture

Status: Reviewed & tested by the community » Needs work

So I can't seem to work around #3153677: Lockfile hash is wrong in 8.9.x since 8.9.1, causing test failures on PHP 7.3+ right now for 8.9.x. However, the failure on 9.1.x means something else is deeply wrong. It has:

	Test Result (3,655 failures / ±0)
#slow.Drupal\Tests\system\Functional\Module\InstallUninstallTest.Drupal\Tests\system\Functional\Module\InstallUninstallTest
#slow.Drupal\Tests\system\Functional\Module\InstallUninstallTest.Unknown
#slow.Drupal\Tests\system\Functional\UpdateSystem\UpdatePathTestBaseFilledTest.Drupal\Tests\system\Functional\UpdateSystem\UpdatePathTestBaseFilledTest
#slow.Drupal\Tests\system\Functional\UpdateSystem\UpdatePathTestBaseFilledTest.Unknown
#slow.Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTrayBlockFormTest.Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTrayBlockFormTest
#slow.Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTrayBlockFormTest.Unknown
#slow.Drupal\KernelTests\Core\Extension\ModuleConfigureRouteTest.Drupal\KernelTests\Core\Extension\ModuleConfigureRouteTest
#slow.Drupal\KernelTests\Core\Extension\ModuleConfigureRouteTest.Unknown
#slow.Drupal\Tests\workspaces\Kernel\WorkspaceIntegrationTest.Drupal\Tests\workspaces\Kernel\WorkspaceIntegrationTest
#slow.Drupal\Tests\workspaces\Kernel\WorkspaceIntegrationTest.Unknown

And clicking on the first of those:

Testing Drupal\Tests\system\Functional\Module\InstallUninstallTest
E                                                                   1 / 1 (100%)

Time: 1.29 seconds, Memory: 4.00 MB

There was 1 error:

1) Drupal\Tests\system\Functional\Module\InstallUninstallTest::testInstallUninstall
Drupal\Core\Extension\InfoParserException: The 'core_version_requirement' constraint (9.1.0-dev) requires the 'core' key not be set in core/modules/views/tests/modules/views_config_entity_test/views_config_entity_test.info.yml

/var/www/html/core/lib/Drupal/Core/Extension/InfoParserDynamic.php:88
/var/www/html/core/lib/Drupal/Core/Extension/InfoParser.php:22
/var/www/html/core/includes/module.inc:88
/var/www/html/core/includes/install.inc:1120
/var/www/html/core/includes/install.core.inc:1520
/var/www/html/core/includes/install.core.inc:461
/var/www/html/core/includes/install.core.inc:115
/var/www/html/core/lib/Drupal/Core/Test/FunctionalTestSetupTrait.php:286
/var/www/html/core/tests/Drupal/Tests/BrowserTestBase.php:576
/var/www/html/core/tests/Drupal/Tests/BrowserTestBase.php:400
/var/www/html/core/modules/system/tests/src/Functional/Module/ModuleTestBase.php:27
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:691

ERRORS!
Tests: 1, Assertions: 0, Errors: 1.
Lendude’s picture

Status: Needs work » Needs review
FileSize
455 bytes
4.84 KB

Lets take the core key out of the new test module and see how that goes now

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

I've ran the test without the fix. Getting LogicException: Getting the base fields is not supported for entity type Test config entity type with Views data. so this looks create. Nice to have test coverage.

Committed e685313 and pushed to 9.1.x and 9.0.x. Thanks!
Committed 15e0b54 and pushed to 8.9.x. Thanks!

There was a merge conflict with 8.9.x but it was simple to resolve on commit.

diff --git a/core/modules/views/tests/src/Kernel/ViewsConfigUpdaterTest.php b/core/modules/views/tests/src/Kernel/ViewsConfigUpdaterTest.php
index 5dc26defec..9a94a0de25 100644
--- a/core/modules/views/tests/src/Kernel/ViewsConfigUpdaterTest.php
+++ b/core/modules/views/tests/src/Kernel/ViewsConfigUpdaterTest.php
@@ -23,7 +23,7 @@ class ViewsConfigUpdaterTest extends ViewsKernelTestBase {
   /**
    * {@inheritdoc}
    */
-  public static $modules = ['views_config_entity_test'];
+  protected static $modules = ['views_config_entity_test'];
 
   /**
    * {@inheritdoc}

Fixed on commit.

  • alexpott committed e685313 on 9.1.x
    Issue #3143316 by Lendude, sunset_bill, daffie, xjm, facine: "Getting...

  • alexpott committed 491c40a on 9.0.x
    Issue #3143316 by Lendude, sunset_bill, daffie, xjm, facine: "Getting...

  • alexpott committed 15e0b54 on 8.9.x
    Issue #3143316 by Lendude, sunset_bill, daffie, xjm, facine: "Getting...
sunset_bill’s picture

I can see how this works, but Lullabots taught us that when a dependency changes from returning an empty value to throwing an exception, we needed to change our code to catch the exception. What about content entities that don't allow bundles or implement a views data class?

daffie’s picture

@sunset_bill: If you think that there are other cases that are not solved with the current patch then please create a new issue and link it to this issue.

  • xjm committed f501138 on 8.9.x
    Revert "Issue #3143316 by Lendude, sunset_bill, daffie, xjm, facine: "...
xjm’s picture

Status: Fixed » Needs work

After this commit, HEAD is failing on all environments. I don't know if it was a conflict with another patch or what, but I've reverted it for now.

alexpott’s picture

Status: Needs work » Needs review
FileSize
574 bytes
4.84 KB

Whoops. And boo public static $modules

catch’s picture

Status: Needs review » Reviewed & tested by the community

RTBC assuming it comes back green.

  • xjm committed d0ced28 on 8.9.x
    Issue #3143316 by Lendude, sunset_bill, alexpott, daffie, xjm, facine: "...
xjm’s picture

Status: Reviewed & tested by the community » Fixed

Committed the hotfixed patch to 8.9.x. Thanks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.