DoctrineBundle: Either explicitly define DBAL connections error with version 2.4.1

I think broken thousands of application to fixe a few that don’t understand the standard way of using symfony configuration is a bad idea. If there’s a limitation (more a bug) in symfony config, there’s we’re it should be fixe. Now, for the moment I have to tell all our projects (more than an hundred) to be sure not to update.

I think broken thousands of application to fixe a few that don’t understand the standard way of using symfony configuration is a bad idea. If there’s a limitation (more a bug) in symfony config, there’s we’re it should be fixe. Now, for the moment I have to tell all our projects (more than an hundred) to be sure not to update.

I agree. this is a big BC who can be avoided. A better fix (to my point of view) would have been to drop simple configuration support and add deprecation message for who use it to force multiple configuration usage to avoid config confusion. This fix is braking more stuffs than it fix.

This will be reverted in 2.4.2 that will be released shortly. I’ve reopened #1337 and we are waiting for ideas for fixing this there. IMO best would be to deprecate whole short syntax.

I think we should revert #1356 as a bugfix and reconsider the issue in light of the feedback we have here. While you’re all here, we would greatly appreciate any ideas to fix #1337 and doctrine/orm#8687 after the revert!

a BC issus like this should have had at least DEPRECATED status in this version, then change in a major version.

And it seem that now we do have to put all doctrine configuration in one file, and take everything that come with others bundles (especially extensions one) into one file. That is breaking symfony way of doing stuff.

I think the issue is that https://github.com/doctrine/DoctrineBundle/pull/1356 introduced an error rather than a deprecation

I’ve setup a simple project to replicate the issue: https://github.com/NoodlesNZ/doctrine_config

clone the repo and run composer install then ./bin/console cache:clear and it should show the error

@NoodlesNZ I have cloned your project, and it shows a config/packages/prod/doctrine.yaml in simple config, and a doctrine/packages/doctrine.yaml in complex config, so the error message is legitimate.

I would fix the first file like so:

--- a/config/packages/prod/doctrine.yaml
+++ b/config/packages/prod/doctrine.yaml
@@ -1,15 +1,17 @@
 doctrine:
     orm:
         auto_generate_proxy_classes: false
-        metadata_cache_driver:
-            type: pool
-            pool: doctrine.system_cache_pool
-        query_cache_driver:
-            type: pool
-            pool: doctrine.system_cache_pool
-        result_cache_driver:
-            type: pool
-            pool: doctrine.result_cache_pool
+        entity_managers:
+            default:
+                metadata_cache_driver:
+                    type: pool
+                    pool: doctrine.system_cache_pool
+                query_cache_driver:
+                    type: pool
+                    pool: doctrine.system_cache_pool
+                result_cache_driver:
+                    type: pool
+                    pool: doctrine.result_cache_pool

If I check with bin/console debug:config, the result looks good 👍

@Webonaute the screenshot you posted show that the SonataMediaBundle extension you provided is considered explicit… and it is, isn’t it? Do you have other files where you do not explicitely define entity managers? That’s what the message is about.

@nicolas-grekas if you want my opinion, you should deprecate single configuration in this version and remove it in a major version. having a simple structure would help preventing merging wrong configuration structure.

Trace debug:

Btw, I don’t even think https://github.com/doctrine/DoctrineBundle/pull/1356 actually fixes the issue when you use the shortened configuration with customized default_entity_manager in some places only. So it breaks working configs without solving the original issue.

And I don’t see why it becomes impossible to define this via prependExtensionConfig anymore. It should be possible, you just need to use same format in prependExtensionConfig as you used in yaml files.

Well, that’s the issue. Bundles using prependExtensionConfig have no way to know what syntax is used in projects.

And error was intentional as well. Deprecation is too weak and would mask legitimate issues that result from this combined approach.

then release it as a major version, not as a minor one

After all, this is also documented at https://symfony.com/doc/current/reference/configuration/doctrine.html#shortened-configuration-syntax

You cannot use them at the same time in a single file. but different files could make different choices before.

So from my POV I’m just making sure documentation is correct. My choice was either error when using mixed approach with multiple ems/connections, or deprecation of whole shortened configuration. Deprecating whole shortened configuration would mean pretty much every application would have to go through this issue in doctrine-bundle 3.0 though, instead of only projects with multiple managers and mixed configurations, so we decided not to go with it.

Projects using mixed approach could still have a working configuration, and you broke BC for them.

I think the all issues with mixed configuration actually come from the fact that the shortened configuration kept the name of the entity manager configurable, by rewriting the configuration based on the separate default_entity_manager config. But it was rewriting that based on the local value of that config, not based on the final value (as the final value was not known yet at that point) and so things would go wrong for projects trying to use a custom name without redeclaring it in all files using the shortened configuration. A solution for that could have been to deprecate using default_entity_manager alongside the shortened config (and in the next major version of the bundle, the shortened config would always configure an entity manager named default)

Please be sure we’re all interested in feedbacks!

Please don’t mix issues in here. snc_redis issue should go elsewhere, preferably to their bug tracker. This issue is only about Either explicitly define DBAL connections in all doctrine-bundle configuration files, or in none of them or Either explicitly define entity managers in all doctrine-bundle configuration files, or in none of them errors. And so far it wasn’t confirmed because nobody provided reproducer.

This issue can happen only if configuration is processed twice. That can happen only if you have multiple doctrine configurations that have to be processed in same environment. Additionally, it can happen only if you have multiple connections/entity managers.

A reproducer project for any of these issues would be appreciated.

@Webonaute I don’t understand why the prepend extension config you are using triggers the exception in the title, IMO the structure is valid as you mentioned. It should work, and if it does not, that’s what should be fixed, right? Can you please debug further?