./bin/console doctrine:schema:create --dump-sql generates invalid SQL #6535

New Issue

admin · 2026-01-22T15:34:37+01:00

admin commented

2026-01-22 15:34:37 +01:00

Originally created by @cmahnke on GitHub (Sep 7, 2020).

Bug Report

Q	A
BC Break	no
Version	2.10.3

Summary

Running ./bin/console doctrine:schema:create --dump-sql creates invalid SQL, the results are prepended with the following line The following SQL statements will be executed:

It's probably better to insert a comment sign before this line or omit it at all, since the user probably knows what to expect when running with --dump-sql: Not some redundant message, but proper SQL.

I'm using DoctrineBundle 2.1.2

Taken from [DoctrineBundle doctrine/dbal#1208] (https://github.com/doctrine/DoctrineBundle/issues/1208)

Current behaviour

Some status message is uncommented part of the SQL

How to reproduce

./bin/console doctrine:schema:create --dump-sql

Expected behaviour

Valid SQL, that can be used by mysql for example.

Originally created by @cmahnke on GitHub (Sep 7, 2020). ### Bug Report | Q | A |------------ | ------ | BC Break | no | Version | 2.10.3 #### Summary Running `./bin/console doctrine:schema:create --dump-sql` creates invalid SQL, the results are prepended with the following line `The following SQL statements will be executed:` It's probably better to insert a comment sign before this line or omit it at all, since the user probably knows what to expect when running with `--dump-sql:` Not some redundant message, but proper SQL. I'm using DoctrineBundle 2.1.2 Taken from [DoctrineBundle doctrine/dbal#1208] (https://github.com/doctrine/DoctrineBundle/issues/1208) #### Current behaviour Some status message is uncommented part of the SQL #### How to reproduce `./bin/console doctrine:schema:create --dump-sql` #### Expected behaviour Valid SQL, that can be used by `mysql` for example.

admin closed this issue

2026-01-22 15:34:37 +01:00

admin commented

2026-01-22 15:34:38 +01:00

@greg0ire commented on GitHub (Sep 7, 2020):

Can you please run grep -rn 'The following SQL statements will be executed' vendor and post the output here?

@greg0ire commented on GitHub (Sep 7, 2020): Can you please run `grep -rn 'The following SQL statements will be executed' vendor` and post the output here?

admin commented

2026-01-22 15:34:38 +01:00

@cmahnke commented on GitHub (Sep 7, 2020):

These are the results:

$ grep -rn 'The following SQL statements will be executed' vendor
vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:78:            $ui->text('The following SQL statements will be executed:');
vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/UpdateCommand.php:110:            $ui->text('The following SQL statements will be executed:');
vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/CreateCommand.php:69:            $ui->text('The following SQL statements will be executed:');

@cmahnke commented on GitHub (Sep 7, 2020): These are the results: ``` $ grep -rn 'The following SQL statements will be executed' vendor vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/DropCommand.php:78: $ui->text('The following SQL statements will be executed:'); vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/UpdateCommand.php:110: $ui->text('The following SQL statements will be executed:'); vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/CreateCommand.php:69: $ui->text('The following SQL statements will be executed:'); ```

admin commented

2026-01-22 15:34:39 +01:00

@greg0ire commented on GitHub (Sep 7, 2020):

I guess this is in fact an ORM issue then. Transfering it to that project.

@greg0ire commented on GitHub (Sep 7, 2020): I guess this is in fact an ORM issue then. Transfering it to that project.

admin commented

2026-01-22 15:34:39 +01:00

@greg0ire commented on GitHub (Sep 7, 2020):

Here is the line where this comes from: 717ef9106c/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/CreateCommand.php (L69)

About your issue, is there an issue because you want to pipe the output to something that can parse SQL? If yes, a solution would be to use getErrorStyle() to send this to the badly named stderr, that should be used for messages targeted at humans. That way you would only get SQL on stdout. But I'm not really sure these queries are targeted at programs. To me they should also go to stderr since they are part of a notification to a human of what is going to happen.

@greg0ire commented on GitHub (Sep 7, 2020): Here is the line where this comes from: https://github.com/doctrine/orm/blob/717ef9106c99abf10ef6dca8091e32ea3fb77a46/lib/Doctrine/ORM/Tools/Console/Command/SchemaTool/CreateCommand.php#L69 About your issue, is there an issue because you want to pipe the output to something that can parse SQL? If yes, a solution would be to use `getErrorStyle()` to send this to the badly named `stderr`, that should be used for messages targeted at humans. That way you would only get SQL on stdout. But I'm not really sure these queries are targeted at programs. To me they should also go to stderr since they are part of a notification to a human of what is going to happen.

admin commented

2026-01-22 15:34:40 +01:00

@cmahnke commented on GitHub (Sep 8, 2020):

You're right, I've tried to used it in a multi staged Docker build. Currently I've just added a sed before writing the results...
Except from the line it's reusable by mysql - is you r concern, that the SQL dialect can't be specified?
In general it's always better to design for machine readability - it usually allow other to implement things that the original developer didn't even think about...

@cmahnke commented on GitHub (Sep 8, 2020): You're right, I've tried to used it in a multi staged Docker build. Currently I've just added a `sed` before writing the results... Except from the line it's reusable by `mysql` - is you r concern, that the SQL dialect can't be specified? In general it's always better to design for machine readability - it usually allow other to implement things that the original developer didn't even think about...

admin commented

2026-01-22 15:34:40 +01:00

@greg0ire commented on GitHub (Sep 8, 2020):

My only concern is that it's not what this was meant for, but after a closer look, the option description does say "Instead of trying to apply generated SQLs into EntityManager Storage Connection, output them."

I think if you want to contribute this move to stderr, it will be accepted, and you can add tests to make sure no one breaks this in the future, asserting that stdout contains the sql queries, nothing more, nothing less.

@greg0ire commented on GitHub (Sep 8, 2020): My only concern is that it's not what this was meant for, but after a closer look, the option description does say "Instead of trying to apply generated SQLs into EntityManager Storage Connection, output them." I think if you want to contribute this move to `stderr`, it will be accepted, and you can add tests to make sure no one breaks this in the future, asserting that `stdout` contains the sql queries, nothing more, nothing less.

admin commented

2026-01-22 15:34:40 +01:00

@glaszig commented on GitHub (Jul 16, 2022):

given the description of the --dump-sql flag and the semantics of "dump" and "sql" this comment should not event be there in any case. it's completely useless. i constantly use the command and need to go into my generated file and remove the file and leading spaces.

  --dump-sql        Instead of trying to apply generated SQLs into EntityManager Storage Connection, output them.

this issue has been dangling around forever now.

related #7186.

@glaszig commented on GitHub (Jul 16, 2022): given the description of the `--dump-sql` flag and the semantics of "dump" and "sql" this comment should not event be there in any case. it's completely useless. i constantly use the command and need to go into my generated file and remove the file and leading spaces. --dump-sql Instead of trying to apply generated SQLs into EntityManager Storage Connection, output them. this issue has been dangling around forever now. related #7186.

admin commented

2026-01-22 15:34:40 +01:00

@greg0ire commented on GitHub (Jul 16, 2022):

@glaszig fix it then, what are you waiting for? This bug does not affect me.

@greg0ire commented on GitHub (Jul 16, 2022): @glaszig fix it then, what are you waiting for? This bug does not affect _me_.

admin referenced this issue

2026-01-22 16:06:10 +01:00

[PR #6535] [master] PHPStan integration - levels 0 + 1 #10022

Sign in to join this conversation.