-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[RFC] Refactor caching of Translator component #28851
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The container should only have FileExistenceResource, not FileResource, as it cares about the list of files, not their content.
what makes them shared ? Using the same ConfigCacheFactory does not mean they use the same ConfigCache (each call to the factory creates a separate one, and the router and translator don't use the path). I'm not convinced by the usage of a decorator to register the resource in the catalogue. Knowing which resource to register depends on the implementation details of the loader, which makes it unsuited for being handled by a decorator. |
Indeed it only checks for directories, so it will have
Ah, it seems I misunderstood the code there. Indeed they don't seem to share a cache after all.
In my mind there only were Php, Xml and Yaml loaders, but indeed there is also I'll update my original proposal to take this feedback on board. Thanks! |
@stof I've updated my proposal. Points 1 (extract catalogue loading from Translator), 2 (caching catalogue loader decorator) and 5 (directory loader) still stand. How do you feel about those? |
I just tried to implement the
For these reasons I no longer feel this is something that must be pursued any longer. I'll try to solve the directory bug another way. |
Uh oh!
There was an error while loading. Please reload this page.
Currently the caching of the Translator component is sprinkled all over the place:
FileResourcesFileExistenceResource
s andDirectoryResource
s for translation files so the Container itself will be deemed non fresh when the translation files have changed (see FrameworkExtension#registerTranslatorConfiguration)For some reason the Translator and the Router share the same ConfigCacheFactory (see here and here)as @stof pointed out this isn't trueThis has the following drawbacks:
When the routing configuration changes the translator has to be rebuilt and vice versa (because of the shared ConfigCacheFactory)as @stof pointed out this isn't trueProposal to solve these drawbacks:
SelfCheckingResourceInterface
, so it can indicate to the Container when it's no longer fresh - the container no longer needs to concern itself with that. This also decouples the Translator cache from the Router cache.Remove the notion of caching from the FileLoader class- as @stof pointed out this isn't going to work because the decorator would need too much knowledge about what it's decoratingAdd a CacheAwareFileloader that decorates all FileLoaders to add caching (add FileResource to catalogue on load). Symfony Framework would use this decoration by default, but for the Translator component it's optional.- as @stof pointed out this isn't going to work because the decorator would need too much knowledge about what it's decoratingAdd a CacheAwareDirectoryLoader that decorates DirectoryLoader to add the notion of caching (add DirectoryResource to catalogue on load). Symfony Framework would use this decoration by default, but for the Translator component it's optional.- as @stof pointed out this isn't going to work because the decorator would need too much knowledge about what it's decoratingThere are still a lot of implementation details to be considered, but this is the broad overview.
I'd love to hear what people think about this proposal!
If anything is unclear I'd love to clarify - ask me anything!
Also, I'd be willing to create a PR for this if this RFC gets accepted
The text was updated successfully, but these errors were encountered: