Hello Fabien, i am working on the Doctrine 2.0.1 release today, so if you want to take it feel free :-) Johannes had one objection, that the listeners would still be injected for all requests, so he proposed to make this a compiler pass instead and re-use the compiler pass in the console command if its to be done manually. I am not sure what the better approach is here, i don't grasp the internals of the event dispatcher enough.
greetings, Benjamin On Sun, 23 Jan 2011 15:32:32 +0100, Fabien Potencier <[email protected]> wrote: > Excellent idea! but I would not named it container.dumped. What about > "core.prime_cache"? > > Do you want to work on the implementation? If not, I have some time this > afternoon. > > Fabien > > -- > Fabien Potencier > Sensio CEO - symfony lead developer > sensiolabs.com | symfony-project.org | fabien.potencier.org > Tél: +33 1 40 99 80 80 > > On 1/23/11 3:04 PM, Benjamin Eberlei wrote: >> Hello everyone, >> >> let me run an idea through you all. There is a lot of complaints and >> confusion about Doctrine 2 Proxies having to be generated explicitly in >> the >> Production environment. Forgetting this will kill your application >> compared >> to the dev env where auto generation of proxies is done on a per request >> basis. I agree that this is annoying and hence put fort the idea of a new >> event "container.dumped". This event will be fired inside Kernel only >> when >> a new container was dumped. >> >> A new listener "PrimeCacheListener" will be put on this event if any only >> if a parameter "auto_prime_caches: true" is enabled in the "web" >> extension. >> This listener collects a bunch of services tagged "cacheprimer". A cache >> primer can then go and "prime its own caches", this means a >> DoctrineProxyCachePrimer will automatically generate the proxies on the >> first and only first request that generates a new production container. >> >> The same could go for twig template rendering, Doctrine DQL to SQL cache >> generation or any other cache priming mechanisms such as asset >> minification >> and such stuff. >> >> If "auto_prime_caches: false" we should add an console option to the >> still >> to be written "clear cache" command, so that you can call "./app/console >> cache:clear --prime-caches" and it would do the same magic as if >> "container.dumped" was listened too. >> >> This way you can decide for high load environments if you want to prime >> the caches before taking the webserver live again or if you don't care >> because the amount of visitors on your page won't produce a cache slam on >> the first regeneration of the container. >> >> Any comments? >> >> greetings, >> Benjamin >> -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
