-
-
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
Unable to execute orm:generate-proxies #6512
Comments
Please provide steps to reproduce the issue. |
Hi @derrabus, sure, I have created a repo in order to reproduce the error https://github.com/Alvaro948/doctrine-starter, on main branch will find ./bin/doctrine orm:generate-proxies ./var/doctrine/proxies It will work, however, if you switch to branch "updated", re-execute |
I've created #6513 to make the configuration error more explicit. |
Hi @derrabus thanks for your answer, Yes, by setting the env variables it "fixes" the issue, but note that version 4.0.4 did not have this requirement, and most importantly why it this needed in the first place?, I mean, the command is about generating doctrine proxies using the source code, a database connection should not be needed (In my particular use case I execute this command on a CI). However, I have tried what you suggest without luck, for example, by setting the user & password to $connection = DriverManager::getConnection([
'driver' => 'pdo_pgsql',
'user' => null,
'password' => null,
'host' => null,
'port' => null,
'dbname' => null,
'charset' => 'UTF8',
], $config); This, and other combiantions, still fails on version Maybe I have missundertood your answer, as far as I can tell the problem here seems to be that version |
This is something we cannot fix it in the DBAL. Long story short: Connections are lazy in DBAL. You can create a connection with invalid parameters and it's fine until you perform any operation that requires an active connection. When loading the class metadata, which the ORM needs to build the proxies, the ORM fetches the database platform object. In order to create that object, we need to know what DBMS we connect to and usually also to which version of that DBMS. So the DBAL establishes a connection in order to detect the server version. Of course, we could question why fetching the class metadata depends on the database platform, but again: That's an ORM issue and out of scope for this repository.
Yeah, funny story. Well, in DBAL 4.0, we dropped support for Postgres versions before 10. Because of that, we were in the unique situation that we only had a single platform class for all Postgres versions. Since the server version was irrelevant, we could pick the platform class soley based on the driver, so no connection was established. In 4.1, a new platform class for Postgres 12 and above was added, so we again need to know the server version when detecting the platform. However, there is a way to short-circuit the platform detection. If you add |
See doctrine/DoctrineBundle#351 for a similar discussion. |
I'm closing the issue now because there's nothing we can do in DBAL to solve it. |
Hi @derrabus, Yes, I have tried by simply adding $connection = DriverManager::getConnection([
'driver' => 'pdo_pgsql',
'user' => getenv('DATABASE_USERNAME'),
'password' => getenv('DATABASE_PASSWORD'),
'host' => getenv('DATABASE_HOST'),
'port' => getenv('DATABASE_PORT'),
'dbname' => getenv('DATABASE_DATABASE'),
'charset' => 'UTF8',
+ 'serverVersion' => '16.4',
], $config); Also, by simply setting other driver than Again, thank you so much for your help! |
| Q | A |------------- | ----------- | Type | bug | Fixed issues | #6512 #### Summary If `false` (or anything that is not a string) is passed as `user` or `password`, we run into a `TypeError` because we pass that value as-is to the constructor of PDO. This started to happen after we enabled strict types on our driver classes in 4.0. On 3.9, `false` would implicitly be cast to an empty string which is either desired or leads to more obscure connection errors. We could restore the behavior of 3.9 by adding explicit type casts to the two parameters. But since we don't document `false` as a valid value for either parameter, my preference would indeed be raising an exception.
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. |
Bug Report
Summary
Since the update to version 4.1.0 the command for generating proxies fails
Current behaviour
By executing:
Produces:
How to reproduce
Execute the provided command with
doctrine/[email protected]
Expected behaviour
The same as before, by setting the version back to
4.0.4
the issue is gone:The text was updated successfully, but these errors were encountered: