Cache warmer issue w. Propel
lionelbzv opened this issue · comments
I'm facing a problem when using GeneratorBundle w. Propel ORM (1.6).
This problem occurs when you make change in services, or simply by removing the cache rm -fr app/cache for example. After that, the first call of command line like app/console cache:clear or the first load of a website page fails.
If I redo a app/console cache:clear or reload the website page after this initial issue, it works fine. But a composer update for example will always fail at the end of its process, so it's a very annoying bug.
Stack trace:
~/www/project.test$ app/console cache:clear --env=dev -vvv
[PropelException]
No connection information in your runtime configuration file for datasource [default]
Exception trace:
() at /home/lionel/www/project.test/vendor/propel/propel1/runtime/lib/Propel.php:583
Propel::getMasterConnection() at /home/lionel/www/project.test/vendor/propel/propel1/runtime/lib/Propel.php:561
Propel::getConnection() at /home/lionel/www/project.test/vendor/propel/propel-bundle/Propel/PropelBundle/Security/Acl/MutableAclProvider.php:55
Propel\PropelBundle\Security\Acl\MutableAclProvider->__construct() at /home/lionel/www/project.test/app/cache/dev/appDevDebugProjectContainer.php:2608
appDevDebugProjectContainer->getSecurity_Acl_ProviderService() at /home/lionel/www/project.test/app/bootstrap.php.cache:2155
Symfony\Component\DependencyInjection\Container->get() at /home/lionel/www/project.test/app/cache/dev/appDevDebugProjectContainer.php:2552
appDevDebugProjectContainer->getSecurity_Access_DecisionManagerService() at /home/lionel/www/project.test/app/bootstrap.php.cache:2155
Symfony\Component\DependencyInjection\Container->get() at /home/lionel/www/project.test/app/cache/dev/appDevDebugProjectContainer.php:2647
appDevDebugProjectContainer->getSecurity_AuthorizationCheckerService() at /home/lionel/www/project.test/app/bootstrap.php.cache:2155
Symfony\Component\DependencyInjection\Container->get() at /home/lionel/www/project.test/app/cache/dev/appDevDebugProjectContainer.php:3779
appDevDebugProjectContainer->getTwigService() at /home/lionel/www/project.test/app/bootstrap.php.cache:2155
Symfony\Component\DependencyInjection\Container->get() at /home/lionel/www/project.test/app/cache/dev/appDevDebugProjectContainer.php:404
appDevDebugProjectContainer->getAdmingenerator_Generator_PropelService() at /home/lionel/www/project.test/app/bootstrap.php.cache:2155
Symfony\Component\DependencyInjection\Container->get() at /home/lionel/www/project.test/vendor/symfony2admingenerator/generator-bundle/CacheWarmer/GeneratorCacheWarmer.php:68
Admingenerator\GeneratorBundle\CacheWarmer\GeneratorCacheWarmer->buildFromYaml() at /home/lionel/www/project.test/vendor/symfony2admingenerator/generator-bundle/CacheWarmer/GeneratorCacheWarmer.php:44
Admingenerator\GeneratorBundle\CacheWarmer\GeneratorCacheWarmer->warmUp() at /home/lionel/www/project.test/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/CacheWarmer/CacheWarmerAggregate.php:48
Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerAggregate->warmUp() at /home/lionel/www/project.test/app/bootstrap.php.cache:2641
Symfony\Component\HttpKernel\Kernel->initializeContainer() at /home/lionel/www/project.test/app/bootstrap.php.cache:2411
Symfony\Component\HttpKernel\Kernel->boot() at /home/lionel/www/project.test/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:70
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /home/lionel/www/project.test/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:120
Symfony\Component\Console\Application->run() at /home/lionel/www/project.test/app/console:27
Thank you for helping solving this issue!
I'm not sure if it is directly related to the admingenerator. It looks like the admingenerator depends on your ACL-configuration, which again depends on the Propel configuration. So, it looks like the Propel configuration is not yet ready to process your ACL requests.
Where in your AppKernel.php do you instantiate the Admingenerator bundles? Can you try moving them further down?
Not sure if its related to the admingenerator, but at least, the admingenerator shows a problem because I've no problem without it!
AppKernel.php:
<?php
use Symfony\Component\HttpKernel\Kernel;
use Symfony\Component\Config\Loader\LoaderInterface;
class AppKernel extends Kernel
{
public function registerBundles()
{
$bundles = array(
// Core
new Symfony\Bundle\FrameworkBundle\FrameworkBundle(),
new Symfony\Bundle\SecurityBundle\SecurityBundle(),
new Symfony\Bundle\TwigBundle\TwigBundle(),
new Symfony\Bundle\MonologBundle\MonologBundle(),
new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
new Symfony\Bundle\AsseticBundle\AsseticBundle(),
new Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle(),
new JMS\AopBundle\JMSAopBundle(),
new JMS\SecurityExtraBundle\JMSSecurityExtraBundle(),
// Propel
new Propel\PropelBundle\PropelBundle(),
// FOSUserBundle
new FOS\UserBundle\FOSUserBundle(),
// Admin Generator & dependencies
new Admingenerator\GeneratorBundle\AdmingeneratorGeneratorBundle(),
new JMS\DiExtraBundle\JMSDiExtraBundle($this),
new Knp\Bundle\MenuBundle\KnpMenuBundle(),
new WhiteOctober\PagerfantaBundle\WhiteOctoberPagerfantaBundle(),
new Acme\DemoBundle\AcmeDemoBundle(),
);
if (in_array($this->getEnvironment(), array('dev', 'test', 'stage', 'debug'))) {
$bundles[] = new Symfony\Bundle\DebugBundle\DebugBundle();
$bundles[] = new Symfony\Bundle\WebProfilerBundle\WebProfilerBundle();
$bundles[] = new Sensio\Bundle\DistributionBundle\SensioDistributionBundle();
$bundles[] = new Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle();
$bundles[] = new Elao\WebProfilerExtraBundle\WebProfilerExtraBundle();
}
return $bundles;
}
public function registerContainerConfiguration(LoaderInterface $loader)
{
$loader->load($this->getRootDir().'/config/config_'.$this->getEnvironment().'.yml');
}
}
As you can see, the admingenerator is the last one before the my personal app bundle.
BTW, I've just try to put the admingenerator at last bundle but without change
The reason why you have no problem without the admingenerator is probably due to the fact that there are no other bundles which use the database connection during cache warming...
Did you try this?
yes you're right for sure...
And yes, i've already got a config like the "solving" one.
# Propel Configuration
propel:
dbal:
default_connection: default
connections:
default:
driver: %database_driver%
user: %database_user%
password: %database_password%
dsn: %database_driver%:host=%database_host%;dbname=%database_name%
options:
ATTR_PERSISTENT: false
attributes:
ATTR_EMULATE_PREPARES: true
settings:
charset: { value: UTF8 }
queries: { query: 'set names utf8' }
BTW, I know it's not really solving this issue, but here is a little hack which allow some command to properly finish (composer update for example) by using a global \Exception to catch the problem related to this issue.
GeneratorCacheWarmer->warmUp
/**
* Warms up the cache.
*
* @param string $cacheDir The cache directory
*/
public function warmUp($cacheDir)
{
// return;
echo '*** warmUp'."\n";
echo print_r($this->yaml_datas, true)."\n";
foreach ($this->finder->findAllGeneratorYamls() as $yaml) {
try {
$this->buildFromYaml($yaml);
} catch (GeneratedModelClassNotFoundException $e) {
echo ">> Skip warmup ".$e->getMessage()."\n";
} catch (\LogicException $e) {
echo ">> Skip warmup ".$e->getMessage()."\n";
} catch (\Exception $e) {
echo ">> Skip warmup ".$e->getMessage()."\n";
}
}
}
Although I've got no experience with Propel, it might help you to boot the Propel connection in the warm-up phase: something like this.
You can probably get the config by parsing you YAML file, so that it uses that information. Can you try this?
yes it works if I put this piece of code before the warmUp
if (!\Propel::isInit()) {
\Propel::setConfiguration($config);
\Propel::initialize();
}
But do you think it's a task for admingenerator warmup or something wrong with Propel or Symfony2 init process?
I would say that when a bundle is loaded it's functionality needs to be available if it is relevant for the task. In this case, I think that a database connection is trivial and must be available during the warm-up, as there can be more bundles depending on it, for example for ACL stuff. With that reasoning, to me it is a Propel bug.
It might also be the case that the explicit choose to not make it available during the warm-up, but they should have reasons for that...
Can you post these finding also in the issue on the Propel project to see what their opinion is? I will close this issue now as it is not an specific admingenerator issue, or at least, not in my opinion. However, feel free to create a PR to include the Propel boot code in our warm-up process (with the correct checks to see if the user actually uses Propel offcourse) :)