DoctrineBundle: BC break between 1.6.7 -> 1.6.8 regarding driver selection

In my case I just specified the server_version and it just worked:

doctrine:
    dbal:
        driver: pdo_mysql
        host: '%database_host%'
        port: '%database_port%'
        dbname: '%database_name%'
        user: '%database_user%'
        password: '%database_password%'
        charset: UTF8
        server_version: '5.7' # Dark magic here

I soved doing like this #app\config\config.yml

doctrine:
    dbal:
           default_connection: prod
        connections:
             prod:
                  server_version: 9.4
                  driver: pdo_mysql
                  host: "%database_host%"
                  port: "%database_port%"
                  dbname: "%database_name%"
                  user: "%database_user%"
                  password: "%database_password%"
                  charset: UTF8
                  mapping_types:
                      uuid_binary: binary```

@sebastianfeldmann Good job there. In other words, 99a62a7 just exposed the issue which was just hiding there previously… And now this is marked as an expected BC break in bugfix version…

Anyway, this behavior doesn’t make any sense IMHO. I’m explicitly registering only one connection and default_connection points to this specific connection, so why is the bundle even trying to create a connection that was not requested or even used anywhere? (Also driver defaulting to pdo_mysql is just another crazy assumption, but that’s different story.) 😕

So what should I change to fix this then?

I’m using debian, just run mysql -V

My solution was to just start my database server. -___- Really confusing error message for such a simple problem.

Hello i have the same issue it seems that i need to specify my doctrine dbal server_version, but i can’t find where, here is a tree of my project…:

. ├── app │ ├── AppCache.php │ ├── AppKernel.php │ ├── AppKernel.php~ │ ├── config │ │ ├── config_dev.yml │ │ ├── config_dev.yml~ │ │ ├── config_prod.yml │ │ ├── config.yml │ │ ├── override │ │ │ ├── config.yml │ │ │ ├── routing.yml │ │ │ ├── Services │ │ │ │ ├── entities_manager.yml │ │ │ │ └── forms.yml │ │ │ └── services.yml │ │ ├── parameters.yml │ │ ├── parameters.yml~ │ │ ├── parameters.yml.dist │ │ ├── routing.yml │ │ ├── rsync_exclude.txt │ │ ├── security.yml │ │ └── services.yml │ ├── console │ └── Resources │ └── views │ └── base.html.twig ├── auth.json ├── auth.json.dist ├── bin │ ├── behat -> …/vendor/behat/behat/bin/behat │ ├── console │ ├── cssmin -> …/vendor/tubalmartin/cssmin/cssmin │ ├── doctrine -> …/vendor/doctrine/orm/bin/doctrine │ ├── doctrine-dbal -> …/vendor/doctrine/dbal/bin/doctrine-dbal │ ├── doctrine-migrations -> …/vendor/doctrine/migrations/bin/doctrine-migrations │ ├── php-parse -> …/vendor/nikic/php-parser/bin/php-parse │ ├── phpunit -> …/vendor/phpunit/phpunit/phpunit │ ├── security-checker -> …/vendor/sensiolabs/security-checker/security-checker │ ├── selenium-head │ ├── selenium-headless │ ├── simple-phpunit -> …/vendor/symfony/phpunit-bridge/bin/simple-phpunit │ ├── symfony_requirements │ └── update-app ├── CODING_STANDARD.md ├── composer.json ├── composer.lock ├── composer.phar ├── doc ├── features ├── LICENSE ├── packages.json.dist ├── phpmd.xml

This is taking me hours…

a question i try to move symfony to heroku; in local works fine but when i deplay on heroku i found this error … what is the solution?

thanks

In ConnectionFactory.php line 96:
                                                                                      
         An exception occured while establishing a connection to figure out your pla  
         tform version.                                                               
         You can circumvent this by setting a 'server_version' configuration value    
                                                                                      
         For further information have a look at:                                      
         https://github.com/doctrine/DoctrineBundle/issues/673 

Hi the problem ist not with @mikeSimonson changes introduced with commit 99a62a7c4139c0ccb6969de5eff1447b1a6cbaf4

Applying the commented types even if no "un"commented types exist is a valid fix.

Analysis

After consulting wit @Ocramius the assumption is, that because now CommentedTypes are always registered, doctrine tries to register them on the predefined default_connection.

The problem is that we are now registering types on a connection we don’t use, or in this case isn’t woking at all.

Solution

A solution would be to handle the type registration within DBAL but because of this breaking backwards compatibility the only thing we can do right now is to throw some more descriptive exception so the user understand the problem.