Dbal: PDO exception on version 2.6.2

[daanhaitsma]

SQLSTATE[HY000]: General error: PDO::ATTR_STATEMENT_CLASS requires format array(classname, array(ctor_args)); the classname must be a string specifying an existing class

I believe that in Doctrine/DBAL/Driver/PDOConnection.php on line 44, the class Doctrine\DBAL\Driver\PDOStatement cannot be found.

I am using Laravel version 5.5.2 and PHP version 7.1.8

[Ocramius]

https://github.com/doctrine/dbal/blob/8d18a33043edd1dd0b2a996262b67523e1b83f05/lib/Doctrine/DBAL/Driver/PDOStatement.php#L28 - the class is there

[daanhaitsma]

I know, I have the file as well, but the PDOConnection does not appear to be able to find it.

[Ocramius]

@daanhaitsma try writing a minimal reproducible test scenario

[JillevdW]

Any update on the status of this issue? I'm running into this exact issue.

[morozov]

@JillevdW could you provide a minimal reproducible test scenario?

[JillevdW]

@morozov I'm not sure what's required to reproduce this issue; it happens on my live server, while it doesn't happen on my stage server.

[morozov]

@JillevdW you can try comparing server configurations and seeing what could be the difference causing the issue (e.g. PHP version, set of installed extensions, php.ini, etc.).

Without being able to reproduce the issue, we cannot fix it. Sorry.

[DimaUlyanets]

Had the same issue after updating composer a moment ago. Fixed that issue by rolling back:

• Removing doctrine/common (v2.8.1)
  
  
  
  • Installing doctrine/common (v2.7.3)
  
  

• Removing doctrine/dbal (v2.7.0)
• Installing doctrine/dbal (v2.5.13)

PHP - 7.1.5
Ubuntu - 16.04

[imonroe]

I have been fighting the same problem myself all afternoon. The tip from DimaUlyanets above got me back on the right track.

I manually set the versions of doctrine/common and doctrine/dbal in my composer.json file, and then rebuilt my app.

relevant settings in composer.json:

"laravel/framework": "5.5.*",
"doctrine/common": "2.7.0",
"doctrine/dbal": "2.5.13"

It was strange, because in my local development environment (homestead) everything was working great. It only caused me problems when I tried to deploy my code to my dev server, which rebuilds the whole app as part of the deployment process.

[morozov]

@imonroe assuming it's a DBAL issue, the Laravel version is irrelevant. Could you provide a simple script which reproduces this issue with the given composer dependencies?

[imonroe]

I am not sure how to trigger it reliably. I found my way here by Googling error messages. I was seeing on every page page that required authentication:

SQLSTATE[HY000]: General error: PDO::ATTR_STATEMENT_CLASS requires format array(classname, array(ctor_args)); the classname must be a string specifying an existing class 

It looked from the stack traces that it was being triggered because of some kind of discrepancy between the User class and the underlying users table, but beyond that I was stumped, because it seemed to work just fine locally. FWIW, my User class had not changed, and is now working fine again with the rolled back packages.

I'm using php7.0-fpm on ubuntu 17.10 on my dev server, along with Redis as a caching driver, if that might make a difference.

[morozov]

@imonroe given you have access to the environment it's reproducible in, could you try running a sample project like the following and see if it's sufficient?

{
  "require": {
    "doctrine/common": "2.7.0",
    "doctrine/dbal": "2.5.13"
  }
}

<?php

require __DIR__ . '/vendor/autoload.php';

$conn = \Doctrine\DBAL\DriverManager::getConnection([
    // your connection parameters
]);

$conn->query('SELECT * FROM table');

Until we make it reproducible, we cannot fix it.

[morozov]

Interestingly, similar non-reproducible PDO-related issues (#2628, #2847) were also reported by Laravel users. Is it possible that Laravel somehow bypasses the requirement for PDO in composer.json and lets you use the DBAL without the extension?

[imonroe]

I tried the version that was originally in my composer.json, which was causing me problems:

composer.json:

{
    "minimum-stability": "stable",
    "require": {
        "doctrine/dbal": "^2.5"
    }
}

script.php:

<?php
require __DIR__ . '/vendor/autoload.php';
$conn = \Doctrine\DBAL\DriverManager::getConnection([
    'dbname' => 'name',
    'user' => 'user',
    'password' => 'xxxxxxx',
    'host' => '127.0.0.1',
    'driver' => 'pdo_mysql',
]);
$statement = $conn->fetchAll('SELECT * from users');
echo( var_export( $statement, true) );

I did a standard composer update, which pulled in:

  Package operations: 7 installs, 0 updates, 0 removals
  - Installing doctrine/lexer (v1.0.1): Loading from cache
  - Installing doctrine/inflector (v1.3.0): Loading from cache
  - Installing doctrine/collections (v1.5.0): Loading from cache
  - Installing doctrine/cache (v1.7.1): Loading from cache
  - Installing doctrine/annotations (v1.6.0): Loading from cache
  - Installing doctrine/common (v2.8.1): Loading from cache
  - Installing doctrine/dbal (v2.7.0): Loading from cache

Running from CLI, with PHP 7.1.11-1+ubuntu17.10.1+deb.sury.org+1 (cli)
And that works with no problems, exactly like I would expect.

HOWEVER!

When I try to run the same script via a web browser, I get a 500 error.
I went into my nginx log, and I see:

"PHP message: PHP Fatal error: Uncaught TypeError: Return value of Doctrine\DBAL\DriverManager::_checkParams() must be an instance of Doctrine\DBALvoid, none returned in /path/to//debugging/vendor/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php:222

Stack trace:

0 /path/to/debugging/vendor/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(165): Doctrine\DBAL\DriverManager::_checkParams(Array)

1 /path/to/debugging/script.php(4): Doctrine\DBAL\DriverManager::getConnection(Array)

2 {main}

thrown in /path/to/debugging/vendor/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php on line 222" while reading response header from upstream, client: 24.148.94.237, server: myserver.net, request: "GET /debugging/script.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "myserver.net"

You will notice that the the CLI version runs PHP 7.1.11-1+ubuntu17.10.1+deb.sury.org+1 (cli), and the PHP-FPM version runs PHP Version 7.0.28-1+ubuntu17.10.1+deb.sury.org+1 ( according to phpinfo() )

That seems relevant.

So, then I updated my composer.json file, and dumped the vendor directory, and did another composer update.
composer.json:

{
    "minimum-stability": "stable",
    "require": {
        "doctrine/dbal": "2.5.13",
        "doctrine/common": "2.7.0"
    }
}

and that installs thusly:

Package operations: 7 installs, 0 updates, 0 removals
  - Installing doctrine/lexer (v1.0.1): Loading from cache
  - Installing doctrine/inflector (v1.3.0): Loading from cache
  - Installing doctrine/collections (v1.5.0): Loading from cache
  - Installing doctrine/cache (v1.7.1): Loading from cache
  - Installing doctrine/annotations (v1.6.0): Loading from cache
  - Installing doctrine/common (v2.7.0): Loading from cache
  - Installing doctrine/dbal (v2.5.13): Loading from cache

I run the script via CLI, and it works just fine.
I run the script via php-fpm+nginx and it works just fine.

So there's certainly a reproduce-able bug somewhere. Is that useful?

[morozov]

@imonroe ~please check the version of your php-fpm. Looks like it's lower than 7.1 but the code requires ^7.1.~

Looks like you have some other version of DBAL installed. v2.5.13 doesn't have any void:

https://github.com/doctrine/dbal/blob/729340d8d1eec8f01bff708e12e449a3415af873/lib/Doctrine/DBAL/DriverManager.php#L194

[imonroe]

Upgrading PHP-FPM to 7.2 totally did the trick.

[mikeSimonson]

The person who got it working is not the one who filled the issue but it looks like this can be closed now ? @morozov

[amenk]

Had the same problem here. Downgrading to composer require doctrine/dbal=2.6.3 did the trick so far. Whenever; i was not able to reproduce in a minimal example on the same machine using https://github.com/doctrine/dbal/issues/2848#issuecomment-379109082 - either via php cli or with mod_php 7.1.16

[mikeSimonson]

Is the webserver that you use (the env in which you have the issue) also running php 7.1 ?

[amenk]

I just found out it is running PHP Version 7.0.29

[amenk]

I switched to php 7.1 and everything works fine with . Given the case that I composer-installed with php7.1 and then tested with php7.0 nobody can blame DBAL.

[wespiremedia]

Same problem here after composer update, rolled back to 2.6.3 fixed it for now.

[digitlimit]

Issue Resolved
I was getting same error.
I am running Nginx in Ubuntu 16.04, I have php7.1 installed however it turned out Nginx configuration points to php7.0-fpm.sock

Changing php7.0-fpm.sock to php7.1-fpm.sock resolved this issue

[spernica]

We had same error because:
PHP 7.2.2 run on server for our web app, but our cron job run on PHP 7.0.29.

Switching to newer PHP version for cron job helps.