Closed javiereguiluz closed 8 years ago
As far as I can see your problem should be solvable by doing most of the stuff you are currently doing when the container is built in a cache warmer instead (the executed code paths actually are all related to caching data that are expensive to collect, aren't they?).
I've done a super quick test with cache warmers and I'm not sure this would solve our problem.
This is the outline of the code:
public function warmUp($cacheDir)
{
// execute here some complex tasks...
$this->container->setParameter('easyadmin.config', $processedConfig);
}
Problem? Symfony shows this message error:
Impossible to call set() on a frozen ParameterBag.
Why do you need to register the processed config as a container parameter (sorry, I didn't dive too deep into the code for some time, and I will probably need to read a bit to give a more elaborate answer)?
This is what I want:
easyadmin.config
container parameterWhy?
How do we solve this currently?
Well, this could be refactored to introduce something like a configuration provider which is registered as a service and will return the cached configuration (or build it on the fly if needed).
I might have already mentioned this in the past, but IMHO we should have our own metadata system for entities configuration, which will be loaded at runtime, but cached.
Something similar to what exists in Symfony's Serializer and Validator components, with a ClassMetadataFactory
and a list of chained loaders (EasyAdminConfigLoader
& DoctrineMetadataLoader
to start with) able to load/process/complete configuration from different providers/places.
It'll probably avoid requiring those tricky compiler passes, but we'll have to use a doctrine cache system instead of the container's config cache one.
@ogizanagi you are so right! And you even proposed a PR for this: #414 I'll need to review that again very carefully.
I ping this issue because I think it's important to make this change, and as @ogizanagi already worked on it, it can be done quite quickly :)
This is now merged and it will be available in the next version. The compiler pass is gone and replaced by some PHP code + cache warmer + file system Doctrine cache.
Context
Problem
PassConfig::TYPE_BEFORE_REMOVING
) the problem is that the Symfony container is not fully built.twig
service because at that point it's still "synthetic"Solution
What we really need is something that Symfony doesn't provide: execute the compiler pass when the container is fully built and we then modify it.
Alternative solutions (please tell me if they are crazy or legit):
1) During the execution of the backend, check somehow if the backend configuration is fully processed. If not, execute all our "config passes" to build the full configuration. This would slow down only the first request to the backend and then we inject the
easyadmin.config
parameter into the Symfony container.2) "Hack" somehow the compiler pass to allow us use the "real container". Can we compile it somehow temporarily?
I really need help to solve this issue. Thanks!