Symfony 4 迁移：“doctrine.database create command”服务是私有的答案

【问题标题】：Symfony4 migration: The "doctrine.database_create_command" service is privateSymfony 4 迁移：“doctrine.database create command”服务是私有的
【发布时间】：2017-12-30 23:38:48
【问题描述】：

我开始将我的应用程序迁移到 symfony4，但我在我的一个第三方捆绑包 (tbbcmoneybundle) 中有以下弃用通知。我想知道为了提出 PR 需要进行哪些更改

由于这些错误，当前构建失败（完整报告here）

The "doctrine.database_create_command" service is private, getting it from the container is deprecated since Symfony 3.2 and will fail in 4.0. You should either make the service public, or stop using the container directly and use dependency injection instead: 25x
    12x in ConfigTest::setUp from Tbbc\MoneyBundle\Tests\Config
    6x in ConsoleTest::setUp from Tbbc\MoneyBundle\Tests\Console
    3x in ConsoleTest::testRunRatioList from Tbbc\MoneyBundle\Tests\Console
    2x in ConsoleTest::testRunRatioFetch from Tbbc\MoneyBundle\Tests\Console
    1x in ConfigTest::testHistoryOfFetchedRatio from Tbbc\MoneyBundle\Tests\Config
    1x in ConsoleTest::testRunSaveRatio from Tbbc\MoneyBundle\Tests\Console

我猜是和这段代码有关

    $this->runCommand($this->client,'doctrine:database:create');
    $this->runCommand($this->client,'doctrine:schema:update --force');

但是我看不到如何解决这个问题，而且谷歌似乎对此没有帮助。

【问题讨论】：

@gp_sflover 感谢您的指点，但我发现缺少的（我希望用这个问题来填补）是一些关于如何修复它的具体示例
已经做了两个 PR，最后一个是在 3 小时前发布的 Symfony4 support bis。只需等待或让您有空来帮助他们:-)
@gp_sflover 实际上我是制造第二个 MR 的人 :) 并且因为我被这个阻止了，我不想让我的 PR 死掉，因为我没有找到足够的动力将 PR 推到最后。我希望通过尝试在一个非常常见的库（学说）上识别这个特定案例，它可以帮助人们在迁移或贡献自己的 PR 时节省 5~10 分钟。
我真的很累！没看到同名啊啊啊啊啊！我现在没有时间，但明天我会去仔细看看:-)
@gp_sflover 哈哈没问题，你让我检查了两次我的头像和用户名：P 提前感谢你的帮助。

标签： php symfony doctrine-orm symfony3.x symfony4

【解决方案1】：

问题似乎来自于 Symfony 4 中容器意识的丧失（如果这是一个有效的短语），它始于 Symfony 3.4。这个博客talks about restricting container injection in 3.4 and how it will go away in 4.0。

看起来好像有人有opened a PR to upgrade to Symfony 4, but that is failing。（看起来你也在努力帮助它。）

根据this Travis integration test that is failing，扩展“ContainerAwareCommand”的命令是失败的根源。

这是有道理的。 ContainerAwareCommand 尝试注入 Container，它在 Symfony 4 中设置为 private（自 3.4 起已弃用），如上面的博客文章中所述。一个修复，如果我正确阅读了您的问题，我认为您想在对 TBBC 的 PR 中修复此问题，似乎是从这些命令类中删除 ContainerAwareCommand 的扩展并注入必要的服务。请参阅new Symfony 4 doc on commands（请注意，ContainerAware 不再是it was in 2.8-ish 的选项。）

简而言之，摆脱 ContainerAwareCommand 的扩展并注入这些命令使用的服务。（可能需要do some extra configuration to ensure that the services are public。）

【讨论】：

hmmm 在对捆绑包的代码进行了更多调查之后，似乎是因为测试是在弃用通知设置为严格的情况下运行的（如果有弃用通知，则测试失败），但事情即将发生来自 symfony 框架本身，因为它使用的是 3.1，并且这些弃用通知仅在更高版本中内部修复....
我会认为你的答案是正确的，就好像对于这个非常具体的案例它不是“答案”，但它实际上引导我走向正确的方向:)