feat(env): clear the framework cache when the database it was built against changes - #1409
Merged
Merged
Conversation
…gainst changes Repointing a site at another database left it serving errors. A framework caches the container definitions it builds from its configuration, and the cached ones survive the rewrite: after moving a Drupal site from its file database to MySQL, every request died on an entity type the cached container no longer knew about, while the connection lerd had written was correct and drush could bootstrap against it perfectly well. A definition names the console subcommand that clears its caches, and lerd runs it through the console binary the definition already declares, the same way it generates an application key. Every framework spells it differently, so nothing but the definition can say. It runs only when the site actually moved database: the keys are matched against the ones the framework's database services declare, so a rewritten URL or mail setting changes nothing, and a run that writes the same values as before clears nothing. A project whose dependencies are not installed has no cache to clear, and a failure is a warning rather than the end of the run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Repointing a site at another database left it serving errors. A framework caches the container definitions it builds from its configuration, and the cached ones survive the rewrite: after moving a Drupal site from its file database to MySQL, every request died with
while the connection lerd had written was correct, the module was enabled and present on disk, and drush could bootstrap against the new database perfectly well. Only the cache was wrong, and clearing it brought the site back.
A definition names the console subcommand that clears its caches, and lerd runs it through the console binary the definition already declares, the same way it generates an application key. Every framework spells it differently, cr for Drupal, cache:clear for Symfony, optimize:clear for Laravel, so nothing but the definition can say.
It runs only when the site actually moved database. The changed keys are matched against the ones the framework's own database services declare, so a rewritten URL or mail setting is not a reason to rebuild a cache, and a run that writes the same values as before clears nothing. A project whose dependencies are not installed has no cache to clear, and a failure is a warning rather than the end of the run.
The definitions have to name the command for this to do anything, which is a store change and not part of this.
Closes #1408