[FrameworkBundle] Add --watch option to cache:clear command #32764
Conversation
c7afd5d to
56b4c1f
Compare
|
@maidmaid just asking: does it take so much time to clear the cache in your real apps? Maybe they are so big and/or complex that they do. But I'm curious because I usually don't deal with the cache at all and I have no issue. And when I need to clear the cache for some reason, I always run |
|
Yes it does : something like 10'' for a complete cache:clear, and more when I'm working from a vagrant/container. |
There was a problem hiding this comment.
Hi @maidmaid !
I tested your feature in an example project, it seems to be fine for me.
I just notice one thing :
If I'm running cache:clear --watch and then I install a new package like
composer require orm
the autoloader failed and the watch cancelled
https://zupimages.net/up/19/31/p5yj.png
Idk if thats normal
|
Do we need some locking mechanism? |
|
Locking implemented in #33701 |
|
What about relying on #31462 here? Could you please have a look? |
…pportunistic lock (nicolas-grekas) This PR was merged into the 4.4 branch. Discussion ---------- [HttpKernel] wrap compilation of the container in an opportunistic lock | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - #32764 (comment) This PR adds a lock around the compilation of the container. When two or more concurrent requests want to compile the container, the first one runs the computation and the others wait for its completion. If for any reasons the lock doesn't work, compilation happens as usual. The effect is visible when developing locally: Here is what all concurrent requests consume now:  And here is what they will consume with this PR (they wait but reuse the just compiled container):  Commits ------- 0b5b3ed [HttpKernel] wrap compilation of the container in an opportunistic lock
…pportunistic lock (nicolas-grekas) This PR was merged into the 4.4 branch. Discussion ---------- [HttpKernel] wrap compilation of the container in an opportunistic lock | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | - | License | MIT | Doc PR | - symfony/symfony#32764 (comment) This PR adds a lock around the compilation of the container. When two or more concurrent requests want to compile the container, the first one runs the computation and the others wait for its completion. If for any reasons the lock doesn't work, compilation happens as usual. The effect is visible when developing locally: Here is what all concurrent requests consume now:  And here is what they will consume with this PR (they wait but reuse the just compiled container):  Commits ------- 0b5b3ed [HttpKernel] wrap compilation of the container in an opportunistic lock
|
I'm closing because this can be achieved using a composer script, adding e.g. this under the "scripts" section of your composer.json: "auto-cache-clear": [
"while inotifywait -qqre modify -e delete -e create src/ config/; do bin/console cache:clear; done"
]Then running The logic is also too basic: any changes in the app's directories will trigger a cache:clear. This will spam the command to me. It will increase the maintenance effort for sure, as ppl will ask for more fine-grained logic. Better not, especially when this can be achieved already with one line of bash. Thanks for proposing. |
Inspired by the watch of webpack, this PR allows to clear the cache immediately after touching the code base of the project. Indeed, from the DX perspective, the cache regeneration is always painful because it is started after an user action such as running a command or making a request through the browser, and we undergo the time of recompilation that should ideally be realised before.