Report DB version in Status report.

I verified this in person with David, but interestingly it does not occur on a local (laptop) install with PHP 5.2.12 and mysql 5.1.41. Didn't try other versions of php/mysql yet.

note - this also happens when javascript is disabled. So even though the field UI has some weird js-based form stuff, it seems unrelated.

Looking through the code, it seems like about the only way this could happen would be if mysql was holding the result in a query cache and not checking the underlying table?

Looks like a possible cause is this mysql bug: http://bugs.mysql.com/bug.php?id=40386

supposedly fixed in a slightly later version of mysql 5.1 than you have.

Noted in 5.1.31 changelog.

TRUNCATE TABLE for an InnoDB table did not flush cached queries for
the table.

Can you try disabling the query cache (after verifying that you have it running now)?

In combination with http://www.palantir.net/blog/beware-mysql-51-my-son it seems like at install time and when checking requirements Drupal should give you a big warning if you are using mysql 5.1 < 5.1.32

I think it should be made to display a warning message.

Oh for the love of god... Subscribing. It sounds like we're going to have to start supporting only checker-board versions of MySQL, which is going to seriously suck.

There is no reason to support beta versions of MySQL. I'm for a hard failure.

Here are the versions that ships with distributions in the Debian world:

• Debian: Lenny (n) 5.0.51a, Lenny-backports 5.1.47, Testing (future n+1) 5.1.48
• Ubuntu: Hardy (LTS-1) 5.0.51a, Jaunty (n-2) 5.0.75 and 5.1.31, Karmic (n-1) 5.0.83 and 5.1.37, Lucid (LTS) 5.1.41

We are certainly not affected by the issue identified by Crell in everything < 5.1.32 (... I don't understand how it would make sense to UPDATE a NON-NULL column to NULL... that's certainly a bug in the affected module, and this type of craziness will definitely fail on PostgreSQL... much ado about nothing).

As a consequence, I would recommend a hard failure for any version on MySQL 5.0 < 5.0.51a and MySQL 5.1 < 5.1.31.

The problem case is RHEL which apparently has 5.1.30 - I agree they suck, but I suggest an error or warning versus fail.

It can be made to work, but not optimally.

for Drupal 6 here's the Postgres cod:

/**
 * Report database status.
 */
function db_status_report() {
  $t = get_t();

  $version = db_version();

  $form['pgsql'] = array(
    'title' => $t('PostgreSQL database'),
    'value' => $version,
  );

  if (version_compare($version, DRUPAL_MINIMUM_PGSQL) < 0) {
    $form['pgsql']['severity'] = REQUIREMENT_ERROR;
    $form['pgsql']['description'] = $t('Your PostgreSQL Server is too old. Drupal requires at least PostgreSQL %version.', array('%version' => DRUPAL_MINIMUM_PGSQL));
  }

  return $form;
}

/**
 * Returns the version of the database server currently in use.
 *
 * @return Database server version
 */
function db_version() {
  return db_result(db_query("SHOW SERVER_VERSION"));
}

for mysqli:

/**
 * Report database status.
 */
function db_status_report($phase) {
  $t = get_t();

  $version = db_version();

  $form['mysql'] = array(
    'title' => $t('MySQL database'),
    'value' => ($phase == 'runtime') ? l($version, 'admin/reports/status/sql') : $version,
  );

  if (version_compare($version, DRUPAL_MINIMUM_MYSQL) < 0) {
    $form['mysql']['severity'] = REQUIREMENT_ERROR;
    $form['mysql']['description'] = $t('Your MySQL Server is too old. Drupal requires at least MySQL %version.', array('%version' => DRUPAL_MINIMUM_MYSQL));
  }

  return $form;
}

/**
 * Returns the version of the database server currently in use.
 *
 * @return Database server version
 */
function db_version() {
  global $active_db;
  list($version) = explode('-', mysqli_get_server_info($active_db));
  return $version;
}

see also: http://www.php.net/manual/en/mysqli.get-server-info.php

For MySQL we can do:

mysql> SHOW variables LIKE 'version';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| version       | 5.1.41 |
+---------------+--------+
1 row in set (0.00 sec)

for sqlite:

sqlite> SELECT sqlite_version();
3.6.12

So I suggest we add a method to the DB driver interface that reports the server version.

That's a worthwhile thing to do anyway, regardless of what versions we claim to support. Let's split that off to a separate issue.

#878198: Regression: add back a method to the DB driver interface that reports the server version.

Since the version patch is committed here's a stub/starter patch for this.

setting to CNR just for feedback on the method naming, etc.

The connection classes should not contain t() or any other Drupal-specific functions/utilities. It looks like we can move that information out of the classes anyway as they're all identical.

I made a simpler patch.

This is a regression, as D6 reports the database version.

It's really useful to have this information in the status report.

#20: report-db-version.patch queued for re-testing.

It it really useful to use the human-readable name versus the driver name?

Also I notice that PDO makes some additional meta-data available. Should we display that too? Like this?

oops - fixing doxygen.

Yeah - I think it makes more sense for the title to be the same regardless of which db engine is in use.

I don't like the title "Default database server". It isn't default. I prefer "Database system".

The description is looking like:
Uptime: 74917 Threads: 1 Questions: 738396 Slow queries: 0 Opens: 20978 Flush tables: 1 Open tables: 39 Queries per second avg: 9.856

This really clutters up the status report. It belongs on its own page like the PHP "more information" link and should be in a table. phpMyAdmin seems to provide a lot more information. Perhaps this should be in a contrib module.

I think its much better to have the human-readable name.

I played around with different layouts and I think it is better with the version as a separate entry.

Let's at least keep the added method even if we don't use it for this?

Let's split that off to a separate issue.

no, please add it here - it's a trivial addition.

The issue with #25 is that I don't see why we're using the DatabaseTasks class for the human-readable driver name. Then I looked and realized that, OMG, the drivers themselves don't have a human-friendly name method, do they? That should be fixed... except that runs into translation issues and pushes a t() or st() into the driver classes. We can't win. :-(

So bah, I'm calling #25 RTBC. The server info method isn't being used here and the data is easily accessible without the utility method so let's get this committed before RC makes the strings here unchangeable.

Hm. Agreed. And thanks for actually working on string freeze patches. :)

Committed to HEAD.