Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DBAL-1000: MySQL DB cannot be created from Cli, returns "QLSTATE[42000] [1049] Unknown database" #929

Closed
doctrinebot opened this issue Oct 14, 2014 · 10 comments
Assignees
Labels

Comments

@doctrinebot
Copy link

doctrinebot commented Oct 14, 2014

Jira issue originally created by user Marqs:

When trying to create a database via Symfony (tested 2.3, 2.4, 2.5) console using Doctrine, if returns

[Doctrine\DBAL\Exception\ConnectionException]
An exception occured in driver: SQLSTATE[42000] [1049] Unknown database 'livedb_ci_tco_dev'

This effectively prevents re-creating the database.

I traced the error, it seems database existence is either not checked or not functioning, and it tries to connect to the DB, resulting in an exception. In older versions the trace seemed like it checked if DB exists, and didn't try to connect.

I tested some different commit versions to assess where the bug was introduced - here is my brief list of working/non-working versions.

812dd9d (v.2.5.0-BETA3) fail
61eb1ee fail
3176f51 fail
da43b76 works
ce3a56e works
594e326 works
ba9aa63 (v.2.5.0-BETA2) works

So looking from the commit graph, to me it seems like it might have been introduced in commit 3176f51

@doctrinebot
Copy link
Author

Comment created by @Ocramius:

[~Marqs] are you sure that you are running the correct command? If the DB is not there, I would expect an exception.

@doctrinebot
Copy link
Author

Comment created by stof:

[~ocramius] This command is precisely about creating the database when it does not exist yet. I think this failure is related to the guessing of the platform version in DBAL 2.5, which will require connecting to the DB early.

@doctrinebot
Copy link
Author

Comment created by @Ocramius:

[~stof] the screenshot shows the drop command being used

@doctrinebot
Copy link
Author

Comment created by Marqs:

I tested with multiple commands, mainly drop and create were most common.

The difference is in the error that gets produced with the different commits applied - other one gives the "The database is not there" kind of error you would expect. The other version gives an "can't do the operation because I can't connect to the database" even when you try to create it, and gives a similar "can't drop the database because I can't connect to the database" kind of error, which still says it tries to do something weird. My screenshot could've been taken from the create-command too, the error was identical.

I should have a breaking composer.json file in my version control on another machine. I'll try to add that later to facilitate debugging.

@doctrinebot
Copy link
Author

Comment created by @deeky666:

[~stof] you are right, that DBAL now connects early if you request the database platform but that should not be an issue as you may not specify a non-existing database name when connecting to creating a new database, anyways. And as far as I can see the CreateDatabaseDoctrineCommand even explicitly unsets the database name in the connection params here: https://github.com/doctrine/DoctrineBundle/blob/master/Command/CreateDatabaseDoctrineCommand.php#L71-L80 for a "temporary" connection.
Dropping a database still should require the database to be existent so connecting to it before dropping should be fine or am I missing something here?

@doctrinebot
Copy link
Author

Comment created by Marqs:

@Steve Muller - is it tries to create the connection and creates an error also when the database is not supposed to be there, for ex. in create action. Effectively breaking createDatabase command.

When I traced the code, it seemed to go in to the platform version checking, and seemed like it just didn't realize early enough that the DB isn't there (that was my guess - I don't know doctrine internals well enough to say if that's how it's planned to work or not).

@doctrinebot
Copy link
Author

Comment created by @beberlei:

This is an issue in DoctrineBundle that only appears in combination with DBAL 2.5.

The problem is Symfony apparently connects to the database in "Container::get" of the connection already. That has to be fixed.

@chrisguitarguy
Copy link
Contributor

Pretty sure this is/was fixed in doctrine/DoctrineBundle#434 and can be closed here.

Platform detection may may the connection non-lazy and cause issues, however.

@lcobucci
Copy link
Member

Closing as per @chrisguitarguy review.

@lcobucci lcobucci assigned lcobucci and unassigned beberlei Nov 19, 2017
@github-actions
Copy link

github-actions bot commented Aug 3, 2022

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants