Problem/Motivation

#3116128: Add an EntityViewsData handler for improved Views integration added reverse relationships for base entity_reference fields, but it would be great to have these reverse relationships added for bundle plugin provided entity_reference fields as well.

Steps to reproduce

This isn't a bug - but if you create a bundle entity_reference field referencing an entity type, then go to add a view for this entity type there is no "relationship" for the bundle field's host entity.

Proposed resolution

Find and include bundle plugin entity_reference fields before adding all of the reverse relationships.

Remaining tasks

Implement change
Add test (unsure if there is test coverage for this?)

User interface changes

N/A

API changes

N/A

Data model changes

N/A

CommentFileSizeAuthor
#13 3206703-13.patch2.42 KBm.stenta
#12 3206703-12.patch2.49 KBpaul121
#10 interdiff_7-10.txt1.34 KBm.stenta
#10 3206703-10.patch2.31 KBm.stenta
#7 3206703-7.patch2.23 KBpaul121
#6 3206703-6.patch2.22 KBpaul121
#4 3206703-4.patch2.08 KBpaul121

Issue fork entity-3206703

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

paul121 created an issue. See original summary.

paul121 opened merge request !3

paul121’s picture

paul121 commented
Status: Active » Needs review
paul121’s picture

paul121 commented
StatusFileSize
new 3206703-4.patch2.08 KB

Adding a patch that includes the change from #3190436: EntityViewsData Column information not available for computed entity reference fields. The two patches are conflicting and we need both of them for farmOS

paul121’s picture

paul121 commented

@m.stenta and I discovered an odd bug pertaining to these bundle plugin reverse relationships while installing a module. TLDR; I added a commit that fixes the installation issue, although for the specific error we encountered, this still requires modules/site builders to rebuild Views Data sometime after installing a module in order for bundle field reverse relationships to be created for views.

When installing a module that provided an entity reference bundle field named data_stream we got this error:

In DefaultTableMapping.php line 391:
                                                                
  Table information not available for the 'data_stream' field.

It was odd because this error only happened depending some of the time, depending on the order other modules were installed with farmOS. After a long chase hunting down module dependencies, we realized this error only happens when installing this module *after* another module that provides some special views - the issue doesn't seem to be that the module provides views, but these views had a CSV export display. While installing our module, for some reason, the views data was re-built *before* the bundle entity reference field was actually created in the DB. The way the EntityViewsData reverse relationship works, an error is thrown when looking for the entity reference field's table name (code)

Investigating further with a debugger it seems to make sense why this is happening - I could see the views data be rebuilt as part of the router rebuild - which doesn't happen on every install! This is why the CSV export display seems to be an important piece. It's not only that the view has a path, but something else to do with the display mode perhaps... (code)

The Entity module installs bundle field definitions in its implementation of hook_modules_installed(). Looking at the core ModuleInstaller->install() service, this hook *is the very last thing* to be called (code). This is the root of the issue - bundle fields being installed last. It doesn't seem like there's a good way for the entity module to hook in earlier to this process... one option would be for each module to implement hook_install and call the entity.bundle_plugin_installer service at that time.

This all goes to show the need for bundle fields in core! It seems like this would be resolved if bundle fields were installed at the same time as base fields by core.

paul121’s picture

paul121 commented
StatusFileSize
new 3206703-6.patch2.22 KB

Reroll of the patch from #4 to include this fix.

paul121’s picture

paul121 commented
StatusFileSize
new 3206703-7.patch2.23 KB

Oops, had a typo in this last patch, $field->isComputed() should have been $field_definition->isComputed().

m.stenta’s picture

m.stenta
he/him
Primary language English
commented

We may have discovered another case where this patch causes the Table information not available for the '[field-name]' field. error to occur.

Discovered here: https://farmos.discourse.group/t/is-it-possible-to-use-custom-fields-and...

Although, it's actually happening for *base* fields, not *bundle* fields in this case... so maybe it's not related. Requires further digging...

Tl;dr: attempting to add a new base field to an entity via hook_entity_base_field_info() (https://github.com/jgOhYeah/farmOS/blob/5bc149c3e86d79e5d6ca089b51413a30...), along with an implementation of hook_post_update_NAME() to create the field (https://github.com/jgOhYeah/farmOS/blob/5bc149c3e86d79e5d6ca089b51413a30...), the following error occurs when loading update.php (it works fine via drush updb):

The website encountered an unexpected error. Please try again later.
Drupal\Core\Entity\Sql\SqlContentEntityStorageException: Table information not available for the 'owner' field. in Drupal\Core\Entity\Sql\DefaultTableMapping->getFieldTableName() (line 391 of core/lib/Drupal/Core/Entity/Sql/DefaultTableMapping.php).

Drupal\Core\Entity\Sql\DefaultTableMapping->getFieldTableName('owner') (Line: 371)
Drupal\entity\EntityViewsData->addReverseRelationships(Array, Array) (Line: 17)
Drupal\farm_entity_views\FarmEntityViewsData->addReverseRelationships(Array, Array) (Line: 79)
Drupal\entity\EntityViewsData->getViewsData() (Line: 180)
views_views_data()
call_user_func_array('views_views_data', Array) (Line: 392)
Drupal\Core\Extension\ModuleHandler->invoke('views', 'views_data') (Line: 237)
Drupal\views\ViewsData->getData() (Line: 154)
Drupal\views\ViewsData->get('asset') (Line: 91)
Drupal\views\Plugin\Derivative\ViewsEntityRow->getDerivativeDefinitions(Array) (Line: 101)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) (Line: 87)
Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() (Line: 285)
Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() (Line: 175)
Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() (Line: 146)
views_theme(Array, 'module', 'views', 'core/modules/views') (Line: 469)
Drupal\Core\Theme\Registry->processExtension(Array, 'views', 'module', 'views', 'core/modules/views') (Line: 356)
Drupal\Core\Theme\Registry->build() (Line: 255)
Drupal\Core\Theme\Registry->get() (Line: 88)
Drupal\Core\Utility\ThemeRegistry->initializeRegistry() (Line: 69)
Drupal\Core\Utility\ThemeRegistry->__construct('theme_registry:runtime:gin', Object, Object, Array, 1) (Line: 275)
Drupal\Core\Theme\Registry->getRuntime() (Line: 142)
Drupal\Core\Theme\ThemeManager->render('html', Array) (Line: 422)
Drupal\Core\Render\Renderer->doRender(Array, 1) (Line: 201)
Drupal\Core\Render\Renderer->render(Array, 1) (Line: 145)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 564)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 146)
Drupal\Core\Render\Renderer->renderRoot(Array) (Line: 66)
Drupal\Core\Render\BareHtmlPageRenderer->renderBarePage(Array, Object, 'maintenance_page', Array) (Line: 76)
Drupal\Core\ProxyClass\Render\BareHtmlPageRenderer->renderBarePage(Array, Object, 'maintenance_page', Array) (Line: 196)
Drupal\system\Controller\DbUpdateController->handle('info', Object)
call_user_func_array(Array, Array) (Line: 115)
Drupal\Core\Update\UpdateKernel->handleRaw(Object) (Line: 76)
Drupal\Core\Update\UpdateKernel->handle(Object) (Line: 27)

It seems that simply going to update.php causes the Views definitions to be rebuilt, which then attempts to find the database table name for the "owner" field, which hasn't been created yet (because update.php hasn't been run yet).

m.stenta’s picture

m.stenta
he/him
Primary language English
commented

Looking closer, the changes to the patch that @paul121 introduced in #5 above work to prevent that error for *bundle* fields, but they do not cover *base* fields.

However, this is NOT the fault of this patch. The same issue would probably happen without it. Still, since we fix the issue for bundle fields in this patch then perhaps we should also fix it for base fields as well.

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
StatusFileSize
new 3206703-10.patch2.31 KB
new interdiff_7-10.txt1.34 KB

Ok this turned out to be a simple fix, thanks to @paul121's earlier fix, which was easy to replicate for base fields. :-)

Attached is an updated patch, along with an interdiff.

(I also updated some whitespace in the patch to use proper indentations, which you can also see in the interdiff.)

This allowed me to use update.php to create the new base field successfully!

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
Status: Needs review » Needs work

#3190436: EntityViewsData Column information not available for computed entity reference fields has been merged so we need to re-roll this patch.

paul121’s picture

paul121 commented
Status: Needs work » Needs review
StatusFileSize
new 3206703-12.patch2.49 KB

Okay, I've rebased this on 8.x-1.5 and added two new commits to account for the changes in #10 and a relevant change from #3190436: EntityViewsData Column information not available for computed entity reference fields to use hasCustomStorage()

Including a patch file we can use for farmOS.

m.stenta’s picture

m.stenta
he/him
Primary language English
commented
StatusFileSize
new 3206703-13.patch2.42 KB

Rebased against the PHPStan error fixes that were applied in #3615092: missing CacheableMetadata parameter adn PHPStan errors, and re-rolled the patch.