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.
Comment | File | Size | Author |
---|---|---|---|
#35 | 3143316-8.9.x-34.patch | 4.84 KB | alexpott |
#35 | 25-34-interdiff.txt | 574 bytes | alexpott |
#25 | 3143316-25.patch | 4.84 KB | Lendude |
#25 | interdiff-3143316-19-25.txt | 455 bytes | Lendude |
Comments
Comment #2
sunset_bill CreditAttribution: sunset_bill as a volunteer and commentedComment #3
sunset_bill CreditAttribution: sunset_bill as a volunteer and commentedComment #4
sunset_bill CreditAttribution: sunset_bill as a volunteer and commentedComment #5
sunset_bill CreditAttribution: sunset_bill as a volunteer and commentedComment #6
LendudeWhat 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?
Comment #7
sunset_bill CreditAttribution: sunset_bill as a volunteer and commentedThis 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
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().
Comment #8
sunset_bill CreditAttribution: sunset_bill as a volunteer and at WarnerMedia commentedComment #9
sunset_bill CreditAttribution: sunset_bill at WarnerMedia commentedComment #10
sunset_bill CreditAttribution: sunset_bill at WarnerMedia commentedI 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.
Comment #11
sunset_bill CreditAttribution: sunset_bill at WarnerMedia commentedLooking 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.
Comment #12
LendudeClosed #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.
Comment #14
LendudeHere we go with a test and the fix from the other issue. Credited @facine for that. No interdiff because the fix changed.
Comment #17
Lal_fixing coding standard issue
Comment #18
Lal_Comment #19
LendudeLets 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
Comment #21
daffie CreditAttribution: daffie commentedReuploading 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.
Comment #22
xjmIssues and regressions with the data upgrade path are generally critical, so bumping the priority accordingly. Thanks!
Comment #23
xjmThanks for triaging this.
#21 has fails like
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.
Comment #24
xjmSo 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:
And clicking on the first of those:
Comment #25
LendudeLets take the core key out of the new test module and see how that goes now
Comment #26
daffie CreditAttribution: daffie commentedThe removal of
core: 8.x
and the landing of #3153677: Lockfile hash is wrong in 8.9.x since 8.9.1, causing test failures on PHP 7.3+ makes the testbot happy.Back to RTBC.
Comment #27
alexpottI'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.
Fixed on commit.
Comment #31
sunset_bill CreditAttribution: sunset_bill at WarnerMedia commentedI 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?
Comment #32
daffie CreditAttribution: daffie commented@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.
Comment #34
xjmAfter 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.
Comment #35
alexpottWhoops. And boo
public static $modules
Comment #36
catchRTBC assuming it comes back green.
Comment #38
xjmCommitted the hotfixed patch to 8.9.x. Thanks!