Note: I don't have time at the moment to isolate all the variables in this report, but I want to get something out there and throw a patch at the testbot. In the meantime, here's what (I think) I know:
If you have a node with revisioning enabled and you perform a node access respecting query for it (e.g., by viewing the node display page at node/nid
), it causes an uncaught exception:
Query tagged for node access but there is no node table, specify the base_table using meta data.
This seems to be because the base table selection logic in node_query_node_access_alter()
doesn't account for revisioning. In Drupal 7, said logic checked the query table for any fields with foreign keys of node.nid
, whereas in Drupal 8 it only looks for {node}
and {node_field_data}
. But a node with revisions will use the {node_revision}
table. I am admittedly no expert with node access, but it seems (in my limited testing) to work if you just add that table to the list of fallbacks. I'll follow with a patch to see what the testbot says.
Comment | File | Size | Author |
---|---|---|---|
#11 | 10-11-interdiff.txt | 1.77 KB | alexpott |
#11 | 2664748-11.patch | 2.65 KB | alexpott |
#10 | interdiff.txt | 1.94 KB | amateescu |
#10 | 2664748-10.patch | 3.01 KB | amateescu |
#8 | interdiff.txt | 572 bytes | amateescu |
Comments
Comment #2
TravisCarden CreditAttribution: TravisCarden at Acquia commentedComment #3
TheodorosPloumisI had the same problem with the workbench_moderation module and this patch fixes the error.
Comment #4
zerolab CreditAttribution: zerolab at Torchbox commentedHad the same issue described in #1 and #3. The patch sorted out the exception.
The patch is straightforward, but still requires someone with more in-depth knowledge of the node access system in Drupal 8 to cast an eye.
Comment #5
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedWe also need to take the revision data table into account ('node_field_revision'), but it's easier to just get the full list of base tables from the table mapping.
Here's an updated patch with that change and a test.
Comment #7
TravisCarden CreditAttribution: TravisCarden at Acquia commentedThat looks great, @amateescu! Thanks!
Comment #8
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedJust a small update for coding standards in tests :)
Comment #9
alexpottThis comment seems out of date - and also should we prefer node or node_field_data if it is present? I can image there is a performance benefit to joining to them over a revisions table. D7 seems to have this kind of optimisation. 'node' is preferred to all others.
Comment #10
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedHow about something like this?
Comment #11
alexpottI think there's no difference between node and node_field_data in terms of join performance to node_access as they both only have a single row per node... maybe node's primary key of
PRIMARY KEY (`nid`),
will be quicker than node_field_data'sPRIMARY KEY (`nid`,`langcode`),
. But I would expect it to be much quicker that joining to the revisions where there are multiple rows for each node id.Comment #12
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedNice, that looks much better!
Comment #15
catchCommitted/pushed to all three 8.x branches, thanks!
Comment #17
alexpott