Problem/Motivation

In order to obtain a (possible) workspace-specific revision instead of the default one in Views results, the Workspaces module is using an undocumented (and quite obscure) feature from Views' standard join plugin, which allows you to use a "formula" (SQL expression) for left_field only if left_table is NULL.

However, the joins for fields stored in dedicated tables have additional conditions, for example on the langcode or deleted columns, and those conditions need the left_table configuration value to be populated in order to be built correctly.

Proposed resolution

Add a new left_formula configuration option for the standard join plugin and use it in workspaces' views query alter, which would allow us to keep the existing value for left_table unaltered.

Remaining tasks

Review.

User interface changes

Nope.

API changes

API addition: a new left_formula configuration option for the the Standard views join plugin.

Data model changes

Nope.

Original issue summary by @maseyuk

Appologies if this isn't assigned to the right component as im not sure who it lives with

I've just enabled the workspaces module on a website i've upgraded from 8.5.7 to 8.6.0 and a mysql error is produced when I have a view outputting a paragraph field.

So my setup is that I have a paragraph field called "Page sections" and a view that simply outputs this field (Set to display as "rendered entity") in a block. Now if I swap to "Stage" workspace a mysql error is shown on any pages where that block is set to show.

Interestingly the error always refers to the "page" content type but even when viewing other content types with/without the "page sections" field it still produces the same error for the "page" content type rather than the content type being viewing (Guessing on each page view it looks at all content types and is hitting this error first)

This is the error:

Exception in Page sections[page_sections]: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'OR node__field_page_sections.bundle = 'page')

The full query which I believe is coming from Views just trying to output this fields content:

SELECT node__field_page_sections.delta AS node__field_page_sections_delta, node__field_page_sections.langcode AS node__field_page_sections_langcode, node__field_page_sections.bundle AS node__field_page_sections_bundle, node__field_page_sections.field_page_sections_target_id AS node__field_page_sections_field_page_sections_target_id, node__field_page_sections.field_page_sections_target_revision_id AS node__field_page_sections_field_page_sections_target_revisio, node_field_revision.created AS node_field_data_created, node_field_data.nid AS nid, paragraphs_item_field_data_node__field_page_sections.id AS paragraphs_item_field_data_node__field_page_sections_id
FROM
{node_field_data} node_field_data
LEFT JOIN {workspace_association} workspace_association ON node_field_data.nid = workspace_association.target_entity_id AND (workspace_association.target_entity_type_id = :views_join_condition_0 AND workspace_association.workspace = :views_join_condition_1)
LEFT JOIN {node_revision__field_page_sections} node__field_page_sections ON COALESCE(workspace_association.target_entity_revision_id, node_field_data.vid) = node__field_page_sections.revision_id AND node__field_page_sections.deleted = :views_join_condition_2 AND (node__field_page_sections.langcode = .langcode OR node__field_page_sections.bundle = :views_join_condition_4)
INNER JOIN {paragraphs_item_field_data} paragraphs_item_field_data_node__field_page_sections ON node__field_page_sections.field_page_sections_target_revision_id = paragraphs_item_field_data_node__field_page_sections.revision_id
LEFT JOIN {node_field_revision} node_field_revision ON COALESCE(workspace_association.target_entity_revision_id, node_field_data.vid) = node_field_revision.vid
WHERE ((node_field_data.nid = :node_field_data_nid)) AND (node_field_revision.status = :db_condition_placeholder_5)
ORDER BY node_field_data_created DESC;

So the error seems to be around the "AND (node__field_page_sections.langcode = .langcode" with the langcode not having a table?

The steps to reproduce should be:
1) Create a paragraph item
2) Add a paragraph field to a content type
3) Create a block in Views that outputs your paragraph field
4) Set that block to appear on all pages
5) Go to any node regardless of type and set the workspace to "stage"
6) The error will be shown

CommentFileSizeAuthor
#8 2997748.patch7.49 KBamateescu
#8 2997748-test-only.patch2.22 KBamateescu

Comments

maseyuk created an issue. See original summary.

maseyuk’s picture

Version: 8.6.0 » 8.7.x-dev
xjm’s picture

Version: 8.7.x-dev » 8.6.x-dev
Issue tags: +8.6.0 update

Thank you for reporting this!

My guess is that this probably should go to the Paragraphs queue for the Paragraphs maintainer to review the apparent incompatibility between the two modules. Then if it turns out to be an issue that they need fixed in core it can move back here with the specific fix needed. :) Note that Workspaces is experimental (so not supported for production use).

Leaving in the core queue for now to give maintainers a chance to see the issue.

catch’s picture

Are you able to uninstall workspaces and post the query with it uninstalled? This must be the way the workspaces query rewrite is interacting with the view.

maseyuk’s picture

Yeah sure this is the standard MYSQL without workspace installed:

SELECT node__field_page_sections.delta AS node__field_page_sections_delta, node__field_page_sections.langcode AS node__field_page_sections_langcode, node__field_page_sections.bundle AS node__field_page_sections_bundle, node__field_page_sections.field_page_sections_target_id AS node__field_page_sections_field_page_sections_target_id, node__field_page_sections.field_page_sections_target_revision_id AS node__field_page_sections_field_page_sections_target_revisio, node_field_data.created AS node_field_data_created, node_field_data.nid AS nid, paragraphs_item_field_data_node__field_page_sections.id AS paragraphs_item_field_data_node__field_page_sections_id
FROM
{node_field_data} node_field_data
LEFT JOIN {node__field_page_sections} node__field_page_sections ON node_field_data.nid = node__field_page_sections.entity_id AND node__field_page_sections.deleted = '0' AND (node__field_page_sections.langcode = node_field_data.langcode OR node__field_page_sections.bundle = 'page')
INNER JOIN {paragraphs_item_field_data} paragraphs_item_field_data_node__field_page_sections ON node__field_page_sections.field_page_sections_target_revision_id = paragraphs_item_field_data_node__field_page_sections.revision_id
WHERE ((node_field_data.nid = '3')) AND (node_field_data.status = '1')
ORDER BY node_field_data_created DESC

So it looks like this time the query has "AND (node__field_page_sections.langcode = node_field_data.langcode"

So the "node_field_data" data table is included this time

miro_dietiker’s picture

Note that we previously had multiple reports about problems with Views and Entity Reference Revisions / Paragraphs.

In fact, 3 years ago we did a quickfix for some basic views integration with zero test coverage at #2548701-5: Update views integration
We don't use views integration with Paragraphs on our own.

Since then i'm repeatingly requesting contributors to help build basic test coverage for their views based use cases with Paragraphs - without success. For instance, the reverse direction is known to be broken #2799479: Views doesn't recognize relationship to host
IMHO we only officially support use cases that are represented in our test cases or derived from them.

This might be a workspaces problem indeed, but not the place to start IMHO. Let's get basic tests for views based functionality in first. Chances are that you then will find other views related problems that need to be fixed first.

amateescu’s picture

Issue tags: -8.6.0 update

This is not an issue with the upgrade path of Drupal 8.6.0, so removing that tag.

amateescu’s picture

Title: Workspaces and paragraphs » Views query alter for fields stored in dedicated tables are not working properly
Version: 8.6.x-dev » 8.7.x-dev
Status: Active » Needs review
Issue tags: -Paragraphs, -workspace, -views +Workflow Initiative
StatusFileSize
new2.22 KB
new7.49 KB

I looked a bit into this issue and it's not related to Paragraphs, the problem is that workspace's views query alter is not working for fields stored in dedicated tables.

Here's a patch for it :)

amateescu’s picture

Title: Views query alter for fields stored in dedicated tables are not working properly » Views query alter for fields stored in dedicated tables is not working properly
Parent issue: » #2968165: Finish the Views integration

The last submitted patch, 8: 2997748-test-only.patch, failed testing. View results

vijaycs85’s picture

Patch in #8 looks great. Here is few thoughts/comments:

  1. +++ b/core/modules/views/src/Plugin/views/join/JoinPluginBase.php
    @@ -263,7 +298,7 @@ public function buildJoin($select_query, $table, $view_query) {
    +      $left_field = $this->leftFormula ?: "$left_table[alias].$this->leftField";
    

    Is it OK to override field, if there is a formula?

    should this be updated in the docblock?

  2. Though it is not public exposed option (in views UI), should we add a change record as introducing a new option?
vijaycs85’s picture

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

Drupal 8.7.9 was released on November 6 and is the final full bugfix release for the Drupal 8.7.x series. Drupal 8.7.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.8.0 on December 4, 2019. (Drupal 8.8.0-beta1 is available for testing.)

Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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.

amateescu’s picture

Issue summary: View changes
Issue tags: -Needs issue summary update

Thanks for the review @vijaycs85!

Re #11:

1. Yup, the whole point of using a formula is that a field is not enough :)

2. Good point, written a CR here: https://www.drupal.org/node/3096875

Also updated the issue summary.

amateescu’s picture

Does anyone want to hit the RTBC button? :)

daffie’s picture

Version: 8.8.x-dev » 9.1.x-dev
Status: Needs review » Reviewed & tested by the community

Updated the CR with the fact that the setting "left_formula" takes precedence over the setting "left_field".
The added views functionality has been documented and testing is added. It all looks good.
The workspace module is now using the new functionality. Also testing for it is added.
All coding changes look good.
The patch needs to land first in 9.1.
For me it is RTBC.

  • catch committed 4ed33dc on 9.1.x
    Issue #2997748 by amateescu, maseyuk, vijaycs85, daffie: Views query...

  • catch committed 5fddf29 on 9.0.x
    Issue #2997748 by amateescu, maseyuk, vijaycs85, daffie: Views query...

  • catch committed 20330cb on 8.9.x
    Issue #2997748 by amateescu, maseyuk, vijaycs85, daffie: Views query...
catch’s picture

Version: 9.1.x-dev » 8.9.x-dev
Status: Reviewed & tested by the community » Fixed

Committed 4ed33dc and pushed to 9.1.x, cherry-picked to 9.0.x and 8.9.x. Thanks!

Not committing to 8.8.x for now since it's a small API addition.

@daffie fwiw issues can be left against the lowest supported 8.x branch they're relevant for, it makes it easier for committers to scan how far things needs to be cherry-picked back to. Although we always need a 9.x-compatible patch to land first.

daffie’s picture

@catch: Will do. Thank you for the explanation.

Status: Fixed » Closed (fixed)

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

quietone’s picture

publish the cr