Problem/Motivation

If you use the Schema::renameTable() method you should return if the table was renamed or not. But for postgre and sqlite there is not returned value.

Proposed resolution

Its true that you always verify:

    if (!$this->tableExists($table)) {
      return FALSE;
    }

But you can't assume that if the table exist this will be renamed. So, you need to be sure that the table was renamed.

Remaining tasks

Test the patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

adriancid created an issue. See original summary.

adriancid’s picture

adriancid’s picture

adriancid’s picture

daffie’s picture

Status: Needs review » Postponed (maintainer needs more info)

Discussed with @catch - both of us are in agreement the use-case and how this is actually useful needs to be demonstrated. Basically how are we ever going to trigger the return FALSE? All I can see is that we're going to do an extra query for no reason.

As @alexpott said in #2862344-15: Return the returned query value from Schema::dropTable().

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

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

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

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

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.

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.

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

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

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

pameeela’s picture

@adriancid, as part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)".

You haven't provided any further info on the use case since the issue was postponed, do you believe it is still relevant or can it be closed? If relevant can you provide some additional info per #5?

adriancid’s picture

@pameeela When I was working on this issue for me was relevant to know if the table was really renamed or not but at this time I really don't need it. If the decision is to close the issue its fine for me.

pameeela’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)
Issue tags: +Bug Smash Initiative

OK thanks @adriancid, I will close. If anyone feels this should be reopened, please add information about the use case per #5 to the issue summary and set the issue status back to "Active".

Thanks!