When I create a view and add a relationship to the "Taxonomy: terms on node" field, the resultant query only joins to the term_data table and doesn't also join to the term_node table.
Steps to reproduce
- Create node view
- Add a field e.g. nid
- Add a relationship to Taxonomy: Terms on Node
- Select any vocabulary
- Important part: tick the "Require this relationship"
- Preview the view
To work around this I untick the "Require this relationship" checkbox, but it results in a very slow query: #1024832: views_handler_relationship_node_term_data extremely slow.
I took a look at views_handler_relationship_node_term_data.inc and the query method looks to only be adding a relationship to the term_data table. This is fine when the "Require this relationship" checkbox isn't ticked because it joins to the sub-select. But when not ticked, it needs a relationship to the term_node table added prior to the term_data relationship.
I am adding this explicit relationship to the taxonomy in my view because I need terms from multiple vocabs on the same row as the node. When I include the terms by themselves, the node is duplicated.
Comments
Comment #1
merlinofchaos CreditAttribution: merlinofchaos commentedWithout that ticked, the code normally adds term_node instead of the subquery. CAn you export the view exhibiting this and paste the actual query generated in the preview?
Comment #2
5kot CreditAttribution: 5kot commentedThe behaviour I saw was that when the checkbox was not ticked, the sub query was used. The sub query makes sense because you need an IJ between the term_node and term_data tables and a LOJ to the result of that. When ticked, I'd expect to see all IJ's.
Here's the view & the query.
View:
Query:
SELECT node.nid AS nid FROM node node INNER JOIN term_data term_data_node ON .tid = term_data_node.tid
Comment #3
keithm CreditAttribution: keithm commentedI am seeing the same problem on views-6.x-2.16. #1231380: Relationship Taxonomy Related Terms, vocabularies not filtered when require this relationship seems to be a duplicate of this issue.
Comment #4
Dean Reilly CreditAttribution: Dean Reilly commentedI recently ran into this issue myself after updating a project I inherited from Views 6.x-3.0 Alpha 3. The problem stems from the removal of an add_table line in this commit (http://drupalcode.org/project/views.git/commitdiff/1ac96c1f6b4b8bae3e4c5...) which came form issue #834948: After upgrading "Fatal error: __clone method called on non-object in /includes/common.inc on line 1736".
The line was removed as it was causing adjust_join to attempt to clone a NULL object (you can see this in comment #9). However, when adding this table adjust_join should never be called in the first place. This problem obviously has a more far reaching affect and was discovered and resolved independently in this commit (http://drupalcode.org/project/views.git/commitdiff/1f5dafda43b9f43196f99...) from issue #887768: Notice: Undefined index: in views_query->add_table().
The missing line can now be safely re-added to restore this functionality without breaking anything else. I've attached a patch to do just this.
Comment #5
Dean Reilly CreditAttribution: Dean Reilly commentedUpdating status.
@keithm, this seems to be a separate issue which is unrelated.
Comment #7
Dean Reilly CreditAttribution: Dean Reilly commentedComment #8
Dean Reilly CreditAttribution: Dean Reilly commented#4: views-3.x-term_node-table-missing-1409640-5.patch queued for re-testing.
Comment #9
xjmI think this might be a duplicate of #1222324: Fix query access control on relationships (comments) and/or #1349080: node_access filters out accessible nodes when node is left joined.
Comment #10
Dean Reilly CreditAttribution: Dean Reilly commentedThis is a separate issue from those.
Having reread through #834948: After upgrading "Fatal error: __clone method called on non-object in /includes/common.inc on line 1736" though - Dawehner does raise the point that the $term_node variable isn't used in the join. This is a problem as it means the join isn't necessarily happening on the correct table. This affects all current versions of views. I've attached patches for 6.x-3.x, 7.x-3.x and 8.x-3.x and tests demonstrating the issue for the last two.
Comment #11
Dean Reilly CreditAttribution: Dean Reilly commentedComment #12
Dean Reilly CreditAttribution: Dean Reilly commentedComment #13
Dean Reilly CreditAttribution: Dean Reilly commentedUpdated the title to reflect the more general case of the issue.
Comment #15
Dean Reilly CreditAttribution: Dean Reilly commented#12: views-8.x-3.x-fix-taxonomy-term-relationship-1409640-12.patch queued for re-testing.
Comment #16
dawehner#12: views-8.x-3.x-taxonomy-term-relationship-test-1409640-12.patch queued for re-testing.
Comment #18
aspilicious CreditAttribution: aspilicious commentedmerged the patch and the test
Comment #20
aspilicious CreditAttribution: aspilicious commentedComment #21
dawehnerThanks for the port, it looks great!
Comment #22
dawehnerThis still has to be committed to 7.x-3.x
Comment #23
Dean Reilly CreditAttribution: Dean Reilly commentedThe combined patch for 7.x-3.x.
Comment #24
aspilicious CreditAttribution: aspilicious commentedLooks good, needs a newline after the test but the committer can do this I think.
Comment #25
dawehnerI'm sorry for giving the wrong commit credit but i was simply confused by the fact that someone patches 8.x-3.x, so this patch should be a patch to be ported ...
Committed finally to 7.x-3.x
Comment #26
Dean Reilly CreditAttribution: Dean Reilly commentedHey Daniel,
No worries, it's nothing worth getting worked up over and I regret mentioning it now (I shouldn't have skipped breakfast that morning!)
The patch for 6.x-3.x is in #10 and needs to be committed too.
Dean
Comment #27
Dean Reilly CreditAttribution: Dean Reilly commented#10: views-6.x-3.x-fix-taxonomy-term-relationship-1409640-10.patch queued for re-testing.
Comment #28
dawehnerGreat! Committed now to 6.x-3.x as well.