Problem

I would export a revision. So i created a new view of type "content revision" with a filter on "revision id".
I acces to this view with the url "revision/%" where % is a vid

And i had this error :

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'npr.title' in 'field list': SELECT nr.vid, nr.nid, npr.title FROM {node_revision} nr WHERE nr.vid IN ( :vids__0 ); Array ( [:vids__0] => 60 ) in Drupal\node\Plugin\views\argument\Vid->titleQuery() (line 76 of core/modules/node/src/Plugin/views/argument/Vid.php).

Proposed resolution

The current line 76 of vid.php is :

<?php
$results = $this->database->query('SELECT nr.vid, nr.nid, npr.title FROM {node_revision} nr WHERE nr.vid IN ( :vids[] )', array(':vids[]' => $this->value))->fetchAllAssoc('vid', PDO::FETCH_ASSOC);
?>

There is no npr table in the WHERE clause

The first thing to do is to add a "\" before PDO::FETCH_ASSOC
The second is to remove the reference to "npr" on the select

Just for testing I replaced the line 76 by this one :

<?php
$results = $this->database->query('SELECT nr.vid, nr.nid, nr.nid as title FROM {node_revision} nr WHERE nr.vid IN ( :vids[] )', array(':vids[]' => $this->value))->fetchAllAssoc('vid', \PDO::FETCH_ASSOC);
?>

And now my export work well. Of course it's not a correct solution. It's just a dirty and quick fix for remove the PHP fatal error.

CommentFileSizeAuthor
#60 limitbyvid-2628130-60.patch527 bytes_KASH_
#4 core.node_.module_2628130_3.patch1.03 KBcgoffin
#6 sql_error_on_revision_export_from_view.patch1.05 KBlamp5
#11 2628130-11-test-only.patch7.25 KBAnonymous (not verified)
#11 2628130-11.patch8.19 KBAnonymous (not verified)
#24 2628130-24-test-only.patch7.24 KBraman.b
#24 2628130-24.patch9.88 KBraman.b
#24 interdiff_11-24.txt3.77 KBraman.b
#27 interdiff-24-27.txt1.64 KBKrzysztof Domański
#27 2628130-27.patch9.76 KBKrzysztof Domański
#29 interdiff-27-29.txt1.88 KBKrzysztof Domański
#29 2628130-29.patch9.93 KBKrzysztof Domański
#31 interdiff-29-31.txt1 KBKrzysztof Domański
#31 2628130-31.patch10.19 KBKrzysztof Domański
#33 2628130-33.patch10.46 KBraman.b
#33 interdiff_31-33.txt434 bytesraman.b
#34 interdiff-33-34.txt1.66 KBKrzysztof Domański
#34 2628130-34.patch10.4 KBKrzysztof Domański
#36 2628130-36.patch10.41 KBkishor_kolekar
#36 interdiff_34-36.txt1.43 KBkishor_kolekar
#42 2628130-42.patch10.39 KBraman.b
#42 interdiff_36-42.txt887 bytesraman.b
#51 interdiff-2628130-42-51.txt2.15 KBLendude
#51 2628130-51.patch8.35 KBLendude
#59 limitbyvid-2628130-59.patch547 bytes_KASH_
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cmarti created an issue. See original summary.

cmarti’s picture

Title: SQL error on revion export from view » SQL error on revision export from view
cmarti’s picture

Priority: Major » Normal
Issue summary: View changes
cgoffin’s picture

Status: Active » Needs review
FileSize
1.03 KB

I created a patch to fix this issue.

cgoffin’s picture

lamp5’s picture

The same error on 8.3.7
Patch work!

amaisano’s picture

Priority: Normal » Major

So this seems like a pretty major bug (we cannot serve a revisions endpoint in REST w/o this). Is anything being done to fix/incorporate this? Or is there a parent issue somewhere covering this? Why is it even "npr" in the first place?

amaisano’s picture

Version: 8.0.0 » 8.4.2
amaisano’s picture

Version: 8.4.2 » 8.5.x-dev

Any updates?

Anonymous’s picture

Status: Needs review » Needs work

#7:

Why is it even "npr" in the first place?

Just an unsuccessful replacement in a large issue #2057401: Make the node entity database schema sensible:

- $results = $this->database->query('SELECT npr.vid, npr.nid, npr.title...
+ $results = $this->database->query('SELECT nr.vid, nr.nid, npr.title...

But if you're wondering why "npr" instead of "nfr" (node_field_revision table), so just an unsuccessful replacement in an even larger issue #1498674: Refactor node properties to multilingual, where would initially use node_property_revision, but then changed the decision.

#9: It would be great to unite forces with #2945298: Typo in SQL select, where we have a fresh patch.

But it seems to me better to transfer it here (with the addition of credit to @Pasqualle). Because here better IS, and it was created before.

Also we need test for prevent regression. I can help with it, if there is no other who want to.

Anonymous’s picture

#10: Oh, my bad! This was not an unsuccessful renaming, node_revision table has not title column. So, #4 nice fix, @cgoffin! Here #4 patch + quick test.

The last submitted patch, 11: 2628130-11-test-only.patch, failed testing. View results

wmike7’s picture

#11 (#4) Worked here. I thought I had messed up my contextual filter. After looking into the logs I came across the error that led me here.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

amaisano’s picture

Patch #11 passes on the latest build. Can we get this RTBC soon?

amaisano’s picture

What are the next steps to get this into the next patch release?

cgoffin’s picture

Status: Needs review » Reviewed & tested by the community
alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Nice bug find! Yep the query is obviously wrong but I think we need to ask ourselves what is this code really doing?

  /**
   * Override the behavior of title(). Get the title of the revision.
   */
  public function titleQuery() {
    $titles = [];

    $results = $this->database->query('SELECT nr.vid, nr.nid, npr.title FROM {node_revision} nr WHERE nr.vid IN ( :vids[] )', [':vids[]' => $this->value])->fetchAllAssoc('vid', PDO::FETCH_ASSOC);
    $nids = [];
    foreach ($results as $result) {
      $nids[] = $result['nid'];
    }

    $nodes = $this->nodeStorage->loadMultiple(array_unique($nids));

    foreach ($results as $result) {
      $nodes[$result['nid']]->set('title', $result['title']);
      $titles[] = $nodes[$result['nid']]->label();
    }

    return $titles;
  }

Why are we loading the default revisions of a node and then setting the title to the revision's title and returning an array with the result of ->label(). This code looks super odd.

This is what the equivalent code in Drupal 7 is doing:

  /**
   * Override the behavior of title(). Get the title of the revision.
   */
  public function title_query() {
    $titles = array();

    $result = db_query("SELECT n.title FROM {node_revision} n WHERE n.vid IN (:vids)", array(':vids' => $this->value));
    foreach ($result as $term) {
      $titles[] = check_plain($term->title);
    }
    return $titles;
  }

I think the correct fix here is to using the entity query for node and query against all revisions. I think you can use the aggregate entity query trick to get it to return all the titles without fully loading them.

bstan’s picture

This is something of interest for my application, any update on when this will be released will be helpful.

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

Drupal 8.6.x will not receive any further development aside from security fixes. 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.

joseph.olstad’s picture

Great work on this patch.

1) The patch works.

2) Has tests to prove that the patch is indeed fixing something.

I just applied it to Drupal core v8.8.5 and it fixes the same issue that was documented above.

joseph.olstad’s picture

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

still using this patch, now on 8.8.8

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

raman.b’s picture

Addressing #18 and resolving failed test cases from #11 for latest dev branch

The last submitted patch, 24: 2628130-24-test-only.patch, failed testing. View results

Lendude’s picture

+++ b/core/modules/node/src/Plugin/views/argument/Vid.php
@@ -37,15 +29,11 @@ class Vid extends NumericArgument {
-  public function __construct(array $configuration, $plugin_id, $plugin_definition, Connection $database, NodeStorageInterface $node_storage) {
+  public function __construct(array $configuration, $plugin_id, $plugin_definition, NodeStorageInterface $node_storage) {

I'm curious how (if?) we want to handle BC for this? Anything extending this and injecting extra services will throw a fatal error.
Maybe make $database optional, set this to NULL in create and check if its not NULL in the constructor and if it's not NULL we trigger_error()?

Other than that, this looks good.

Krzysztof Domański’s picture

1. Added The \Drupal\node\Plugin\views\argument\Vid constructor parameter $database is deprecated
2. Reorder parameters. Optional parameter should be provided after required.

Lendude’s picture

+++ b/core/modules/node/src/Plugin/views/argument/Vid.php
@@ -37,15 +37,18 @@ class Vid extends NumericArgument {
-  public function __construct(array $configuration, $plugin_id, $plugin_definition, Connection $database, NodeStorageInterface $node_storage) {
+  public function __construct(array $configuration, $plugin_id, $plugin_definition, NodeStorageInterface $node_storage, Connection $database = NULL) {

Since anything extending this will pass the variables in the other order, won't this still lead to a fatal error?

Krzysztof Domański’s picture

Status: Needs review » Needs work

The last submitted patch, 29: 2628130-29.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Krzysztof Domański’s picture

Status: Needs work » Needs review
FileSize
1 KB
10.19 KB

Status: Needs review » Needs work

The last submitted patch, 31: 2628130-31.patch, failed testing. View results

raman.b’s picture

Status: Needs work » Needs review
FileSize
10.46 KB
434 bytes
andypost’s picture

needs work for todo code style

  1. +++ b/core/modules/node/src/Plugin/views/argument/Vid.php
    @@ -41,20 +41,18 @@ class Vid extends NumericArgument {
    +   * @todo https://www.drupal.org/project/drupal/issues/3178818 Remove
    +   *   deprecation layer and add argument type to $node_storage.
    

    needs to be inline with https://www.drupal.org/docs/develop/standards/api-documentation-and-comm...

  2. +++ b/core/modules/node/src/Plugin/views/argument/Vid.php
    @@ -41,20 +41,18 @@ class Vid extends NumericArgument {
    +      @trigger_error('Calling ' . __CLASS__ . '::__construct() with the $database parameter is deprecated in drupal:9.2.0 and will be removed in drupal:10.0.0. See https://www.drupal.org/node/3178412', E_USER_DEPRECATED);
    

    could use __METHOD__ . '()

kishor_kolekar’s picture

Status: Needs work » Needs review
FileSize
10.41 KB
1.43 KB

Worked on comment #35

acrazyanimal’s picture

#36 Works for me! Fixed my issue when trying to use a node's revision ID as a contextual filter on a node revision based view.

tanubansal’s picture

Tested #36 on 9.1
Its working fine for me as well
RTBC

elgandoz’s picture

Tested #36 on 8.9.6 and it works fine for me too! I used in addition to this patch that provides the Contextual filter "Revision ID from URL".
RTBC

elgandoz’s picture

Status: Needs review » Reviewed & tested by the community
Lendude’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/core/modules/node/src/Plugin/views/argument/Vid.php
    @@ -37,15 +36,28 @@ class Vid extends NumericArgument {
    +      @trigger_error('Calling ' . __METHOD__ . '()::__construct() with the $database parameter is deprecated in drupal:9.2.0 and will be removed in drupal:10.0.0. See https://www.drupal.org/node/3178412', E_USER_DEPRECATED);
    

    This isn't in line with what @andypost meant, ::__construct() can be removed when using __METHOD__

raman.b’s picture

Status: Needs work » Needs review
FileSize
10.39 KB
887 bytes

Yes, let's fix that

Lendude’s picture

Status: Needs review » Reviewed & tested by the community

Nice, looks ready now.

joseph.olstad’s picture

On the project page for safedelete I am currently recommending the usage of this core patch, in some situations some warning messages are thrown by core on unpatched systems.

FYI: I just released a new version of the safedelete module supporting checks for referenced embedded media entities.

  • catch committed 7baff21 on 9.2.x
    Issue #2628130 by Krzysztof Domański, raman.b, kishor_kolekar, cgoffin,...

alexpott credited catch.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests
  1. +++ b/core/modules/node/src/Plugin/views/argument/Vid.php
    @@ -37,15 +36,28 @@ class Vid extends NumericArgument {
    +   * @param \Drupal\Core\Database\Connection|null $database
    +   *   Database Service Object.
    

    This will never be a $database object. I'm this argument should be removed.

  2. +++ b/core/modules/node/src/Plugin/views/argument/Vid.php
    @@ -37,15 +36,28 @@ class Vid extends NumericArgument {
    +    if ($node_storage instanceof Connection) {
    

    We also need to ensure that $node_storage is an instance of NodeStorageInterface and error if (once the args are sorted out) it is not. That will allow us to introduce the type hint in D10.

    Also given there is special logic to deal with the argument deprecation thisw does need testing.

  3. +++ b/core/modules/node/src/Plugin/views/argument/Vid.php
    @@ -37,15 +36,28 @@ class Vid extends NumericArgument {
    +      if ($database) {
    +        $this->database = $database;
    +      }
    

    We should use the \Drupal\Core\DependencyInjection\DeprecatedServicePropertyTrait to provide BC for $this->database.

  • catch committed 86de015 on 9.2.x
    Revert "Issue #2628130 by Krzysztof Domański, raman.b, kishor_kolekar,...
catch’s picture

#47 is right, reverted for now.

catch’s picture

Discussed the issue briefly with @alexpott in slack due to the cross-post, and we both think we should split the bugfix from the deprecation.

The deprecation adds most of the complexity to the patch, and it also makes it harder to backport to 9.1.x and 8.9.x - if we do a bugfix-only patch here and backport it, we could then handle the deprecation in 9.2.x-only in a follow-up.

Lendude’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
2.15 KB
8.35 KB

#50 sounds good, here we go

Krzysztof Domański’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs followup

Per #50 it needs follow-up.

alexpott’s picture

Issue tags: -Needs followup

I created #3187435: Deprecate $database argument in \Drupal\node\Plugin\views\argument\Vid::__construct() - @Krzysztof Domański in order to rtbc this patch that really needs to be done. Adding "needs followup" and rtbc in the same comment means that someone else has to do the work.

alexpott’s picture

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

Committed and pushed 4823b803ea to 9.2.x and 0753e71955 to 9.1.x. Thanks!

  • alexpott committed 4823b80 on 9.2.x
    Issue #2628130 by Krzysztof Domański, raman.b, Lendude, kishor_kolekar,...

  • alexpott committed 0753e71 on 9.1.x
    Issue #2628130 by Krzysztof Domański, raman.b, Lendude, kishor_kolekar,...

Status: Fixed » Closed (fixed)

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

kerasai’s picture

No mention of 8.9.x since #51. The test there fails due to visibility on a property in the test class.

I can confirm that the commit to 9.1.x applies successfully to the current 8.9.x release (8.9.18) and works as expected. https://git.drupalcode.org/project/drupal/-/commit/0753e71955013bec8080e...

_KASH_’s picture

FileSize
547 bytes

Wrong code in this patch.

_KASH_’s picture

_KASH_’s picture