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
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 2997748.patch | 7.49 KB | amateescu |
| #8 | 2997748-test-only.patch | 2.22 KB | amateescu |
Comments
Comment #2
maseyuk commentedComment #3
xjmThank 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.
Comment #4
catchAre 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.
Comment #5
maseyuk commentedYeah 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
Comment #6
miro_dietikerNote 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.
Comment #7
amateescu commentedThis is not an issue with the upgrade path of Drupal 8.6.0, so removing that tag.
Comment #8
amateescu commentedI 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 :)
Comment #9
amateescu commentedComment #11
vijaycs85Patch in #8 looks great. Here is few thoughts/comments:
Is it OK to override field, if there is a formula?
should this be updated in the docblock?
Comment #12
vijaycs85Comment #14
amateescu commentedThanks 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.
Comment #15
amateescu commentedDoes anyone want to hit the RTBC button? :)
Comment #16
daffie commentedUpdated 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.
Comment #20
catchCommitted 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.
Comment #21
daffie commented@catch: Will do. Thank you for the explanation.
Comment #23
quietone commentedpublish the cr