Create new database with a table:

CREATE DATABASE test;
CREATE TABLE test (id INT AUTO_INCREMENT PRIMARY KEY COMMENT 'Primary ID of the TEST');
GRANT ALL PRIVILEGES ON test.* TO 'test'@'localhost' IDENTIFIED BY 'test';


settings.php

<?php
$databases['default']['test'][] = array (
  'database' => 'test',
  'username' => 'test',
  'password' => 'test',
  'host' => 'localhost',
  'port' => '',
  'driver' => 'mysql',
  'prefix' => '',
);
?>


Test:

<?php
$comment = Database::getConnection('default')->schema()->getComment('users', 'uid');
var_dump($comment);

$comment = Database::getConnection('test')->schema()->getComment('test', 'id');
var_dump($comment);
?>


Expected result:

string(28) "Primary Key: Unique user ID."
string(11) "Primary ID of the TEST"


Actual result:

string(28) "Primary Key: Unique user ID."
bool(false)

patch coming up ...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gielfeldt’s picture

gielfeldt’s picture

Status: Active » Needs review
mcrittenden’s picture

Status: Needs review » Reviewed & tested by the community

Looks fine to me and seems to work as expected.

gielfeldt’s picture

Version: 7.x-dev » 8.x-dev
Status: Reviewed & tested by the community » Needs review
FileSize
1022 bytes

Here's a D8 version too ...

gielfeldt’s picture

Status: Needs review » Reviewed & tested by the community

Setting to RTBC since patch is identical to the already reviewed 7.x patch, and tests have passed.

catch’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)
Issue tags: +Needs backport to D7

Looks fine. Committed/pushed to 8.x, moving to 7.x for backport.

c960657’s picture

Status: Patch (to be ported) » Reviewed & tested by the community

D7 patch (in comment#1) is identical to D8 patch.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review

This seems to make total sense, but it's also one of the scarier-looking one-line patches I've seen in a while, given its potential for breaking things :) And it hasn't gotten too much in the way of detailed reviews and testing (or comments by people who wrote the code originally), so I think I should hold off committing it to Drupal 7 for a bit in case there's something we're missing here.

I guess my biggest question is how do you hit this issue in practice? AFAIK, database targets are intended to be used for e.g. master/slave setups, in which case the database schema should be the same between the two targets anyway, and therefore it doesn't matter much if the wrong one is queried.

David_Rothstein’s picture

Title: DatabaseSchema_mysql::getComment() does not work for targets other than "default" » Database schema methods like getComment() and findTables() always query the "default" target on MySQL

When I was looking at this I realized (and confirmed) that this issue happens with the findTables() method too.

gielfeldt’s picture

I stumbled upon it while I was developing AutoSlave. I believe the situation arose, when it was actually a connection called [default][master] that was being used for the queries, rather than [default][default] which is part of what AutoSlave does.

There are probably no code paths in core that triggers this error. I don't think we missed something here, I just think the use-case posted in this thread has never arosen.

gielfeldt’s picture

FWIW the postgres driver of course does not have this issue (as the title implicitly states).

gielfeldt’s picture

So can this go RTBC or what?

gielfeldt’s picture

Issue summary: View changes

Why don't we fix this? It has already been committed to D8. Currently only the MySQL implementation is broken in D7. Let's commit it! :-)

Status: Needs review » Needs work

The last submitted patch, 4: 1891728-4-mysql-get-comment.patch, failed testing.

gielfeldt’s picture

#4 has already been committed to D8. #1 for D7 passes. Let's get it in :-)

gielfeldt’s picture

Status: Needs work » Needs review
mgifford’s picture

The patch in #1 is presently in a production version of a panopoly site we have. I'll check back after a few days and confirm that all is running well with this patch.

mgifford’s picture

Status: Needs review » Reviewed & tested by the community

This patch is working just fine on http://openconcept.ca/

greggles’s picture

Looks sane to me.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 7.x - thanks!

And thanks for confirming that this is running on a production site with no problems, @mgifford. That definitely helps get this one in with some confidence.

Status: Fixed » Closed (fixed)

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