-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
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. |
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. |
Comment created by @Ocramius: [~stof] the screenshot shows the |
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. |
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. |
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). |
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. |
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. |
Closing as per @chrisguitarguy review. |
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. |
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
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.
So looking from the commit graph, to me it seems like it might have been introduced in commit 3176f51
The text was updated successfully, but these errors were encountered: