DoctrineBundle: Doctrine DBAL 2.5 Breaks Symfony if DB Doesn't Exist
After updating to DBAL 2.5, Doctrine introduced Doctrine\DBAL\Connection::detectDatabasePlatform()
which is different than 2.4. Now in 2.5, any time a repository is instantiated (not even used) by the DI, we get a PDOException if the DB doesn’t already exist.
Imagine trying to run app/console doctrine:database:create
and getting a “Database doesn’t exist!” error. Repositories as services are very common in most projects, so this is a huge issue.
To illustrate quickly, create a fresh Symfony project, letting composer install the AcmeDemoBundle. Then, while trying to generate an entity, you’ll get the PDOException.
composer create-project symfony/framework-standard-edition symfony-standard
cd symfony-standard
app/console doctrine:generate:entity --entity=AcmeDemoBundle:Foo
[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[HY000] [1049] Unknown database 'testdb'
[Doctrine\DBAL\Driver\PDOException]
SQLSTATE[HY000] [1049] Unknown database 'testdb'
[PDOException]
SQLSTATE[HY000] [1049] Unknown database 'testdb'
About this issue
- Original URL
- State: closed
- Created 10 years ago
- Comments: 108 (77 by maintainers)
Commits related to this issue
- Added server version to avoid DoctrineBundle bug (https://github.com/doctrine/DoctrineBundle/issues/351) — committed to msvrtan/www-nulldevelopment-hr by msvrtan 10 years ago
- Attempt to fix issue through configuration - see https://github.com/symfony/symfony/issues/12278 - see https://github.com/doctrine/DoctrineBundle/issues/351 - see http://www.doctrine-project.org/jira... — committed to OpenConext/Stepup-Middleware by deleted user 9 years ago
- Attempt to fix issue through configuration - see https://github.com/symfony/symfony/issues/12278 - see https://github.com/doctrine/DoctrineBundle/issues/351 - see http://www.doctrine-project.org/jira... — committed to OpenConext/Stepup-Middleware by deleted user 9 years ago
- Fixed access denied database error when executiong console commands - see https://github.com/symfony/symfony/issues/12278 - see https://github.com/doctrine/DoctrineBundle/issues/351 - see http://www.d... — committed to AltCtrlSupr/ACSPanel-Standard by deleted user 9 years ago
- Fix for https://github.com/doctrine/DoctrineBundle/issues/351 — committed to tchapi/brad by deleted user 9 years ago
- fix app/console issue when database not yet exists * by adding server version * see: https://github.com/doctrine/DoctrineBundle/issues/351 and http://www.doctrine-project.org/jira/browse/DBAL-1057 * ... — committed to knutschsoft/swapp by deleted user 9 years ago
- Introduce late assets, due to https://github.com/doctrine/DoctrineBundle/issues/351#issuecomment-112482587 — committed to tchapi/brad by deleted user 9 years ago
- Issue doctrine/DoctrineBundle#351 — committed to soullivaneuh/symfony-standard by soullivaneuh 9 years ago
- Issue doctrine/DoctrineBundle#351 — committed to soullivaneuh/symfony-standard by soullivaneuh 9 years ago
- Issue doctrine/DoctrineBundle#351 — committed to soullivaneuh/symfony-standard by soullivaneuh 9 years ago
- Fix doctrine bug for CI https://github.com/doctrine/DoctrineBundle/issues/351 — committed to alexyaoyang/Neuralyzer by deleted user 8 years ago
- Need to set DBAL server_version for the installer to work if a database table does not exist. See https://github.com/doctrine/DoctrineBundle/issues/351 — committed to SSHVersionControl/git-web-client by bobfloats 8 years ago
- Added mysql server_version Needed to fix this ~~bug~~ feature from doctrine: https://github.com/doctrine/DoctrineBundle/issues/351#issuecomment-75456547 — committed to elkarbackup/elkarbackup by deleted user 8 years ago
- #984: Add db.version parameter in symfony config Trying to solve build problem whan executing php app/console assets:install See this issue: https://github.com/doctrine/DoctrineBundle/issues/351#issue... — committed to SINP-GINCO/ginco by scandel 7 years ago
- adding server version parameter, see https://github.com/doctrine/DoctrineBundle/issues/351 — committed to hexaaproject/hexaa-backend by deleted user 7 years ago
- docker-for-dev: work around https://github.com/doctrine/DoctrineBundle/issues/351 as doctrine tries to connect to the db during composer install thus breaking the docker image build process — committed to hexaaproject/hexaa-backend by deleted user 7 years ago
- Bugfix, version bump v0.30.7, nohook build Fixed a bug that could cause an ISE when some Entity was requested with ID===null Added database_version parameter to work around a DBAL issue (see https://... — committed to hexaaproject/hexaa-backend by deleted user 7 years ago
- Fix cannot create database error See https://github.com/doctrine/DoctrineBundle/issues/351 — committed to chamilo/chamilo-lms by jmontoyaa 7 years ago
- Added Vagrantfile and install script The script must be run from within the VM and will most likely fail because of this bug (https://github.com/doctrine/DoctrineBundle/issues/351). However it contai... — committed to fpapadopou/pde by fpapadopou 7 years ago
- Set server_version in dbal config See: https://github.com/doctrine/DoctrineBundle/issues/351 for more details about the problem. — committed to OpenConext/Stepup-Middleware by MKodde 6 years ago
For know you can simply provide the version of the database server you are connecting to like this:
As a workaround until we find a solution.
@stof sorry to add more comments about this, but I’d like to say that:
server_version
and our apps worked perfectly.cache:clear
and getting database connection errors makes Symfony look stupid and buggy (and it’s not even Symfony’s fault!)I’m seeing lots of problems related to this on Travis, while deploying apps, etc. That’s why I think this is a Doctrine bug that must be fixed.
From what I understand, I problem come from the experience of using symfony (from scratch), so more usually from Symfony Standard Edition.
Given the advantage of specifying the version of the database, why not simply add a parameter in the
app/config/parameters.yml
file?That which would give in the file app/config/config.yml:
and in the file app/config/parameters.yml.dist:
With the dependency
incenteev/composer-parameter-handler
(already required), the configuration can be changed at the Symfony Standard Edition installation.Is not that a good compromise?
Handled in https://github.com/doctrine/dbal/pull/2671
Just set your db version? It’s not hard and it saves you a query per request.
On 9 Mar 2017 3:38 a.m., “Dalibor Karlović” notifications@github.com wrote:
@Ocramius https://github.com/Ocramius in that case, 5.7 is more strict, use that as “lowest common denominator”? I just feel being in a state where you cannot create a DB because you don’t have a DB is wrong and hurtful to experience of new Symfony+Doctrine developers.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/doctrine/DoctrineBundle/issues/351#issuecomment-285288648, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakDWoFFDtvRpcPXlD_f_8D58e0a83ks5rj7qjgaJpZM4DEmKk .
Also, connecting to the database while just getting a repository seems overkill IMO…
getRepository
should return a newly instanciated repository class, but any access to the database (or any other costly operation) should happen later, when using the repository.@kimhemsoe if so, why doesn’t
getPlatform()
assume the lowest common denominator?In the meantime, Symfony standard edition could just ship with a MySQL version set as it does assume MySQL already.
@Soullivaneuh @greg0ire https://github.com/doctrine/DoctrineBundle/issues/561#issuecomment-238904950
Short story, if “getPlatform*” is called at any point and the driver does not know the version, it will try to detect the version.
In the beginning of dbal, there was only one platform per vendor. This have changed but the usage pattern of platforms have not.
@stof sure! First, the relevant package versions used by this app:
When using this config:
Everything works perfect:
If I comment the
server_version
config:Nothing works anymore:
You are probably going to tell me that it’s not Doctrine fault because:
cache:clear
-> cache warmup -> Twig -> Security -> user provider -> database connection.However, please consider that:
Thanks!
This seems because you’re relying in the auto-detection of platform to be used. Configure the platform to be used as part of DoctrineBundle and live happy. =)