[2.1] Unify cache mechanisms #1513
Comments
|
It would also be very good to have those caching mechanisms available for use in the applications themselves as it would make them a very convenient way |
|
👍 This kind of mess with everyone using their own caching providers is what you find in Drupal plugins, each having their own wheel, and it's very unpleasant to work with. |
|
+1. Thus people won't have to make already-exist-wheel bundles, such as mine https://github.com/winzou/CacheBundle (bridge to use Doctrine Cache) |
|
@winzou: Maybe your bundle could be included in the standard distribution of Symfony2 at least? I don't know if making Doctrine use your caching approach could be done easily but for 2.0 release it would be better that having no cache at all. I was actually about to start to work on something similar to your bundle when I've seen this comment. |
|
This bundle cannot be used for Doctrine (or any other places relying on the Doctrine Common implementation) as the cache implementations don't implement the |
|
FYI : the SonataPageBundle provides some cache handlers : https://github.com/sonata-project/SonataPageBundle/tree/master/Cache and their dedicated invalidation mechanism. |
|
IMO, it would be better to use the |
|
IMO it would be better if we had a cache interface in Cache namespace or something, à la PHPCR, that everyone -including doctrine- would extend from or just use as is. We can't build standards on top of the Doctrine namespace. |
|
Yes, that's a good start, for Symfony, but I'd hope for a world where every PHP lib could require 'cache_interface', and 'cache', and where any cache provider library would provide 'cache' and also require 'cache_interface. That should allow any library to use a cache chosen by the user (by requiring any lib that provides cache). I hope to do that with composer. |
|
i agree .. i would like to see https://github.com/liip/LiipDoctrineCacheBundle moved to the Doctrine organization. |
|
I am not sure if the Doctrine team should be responsible for unifying the cache across Symfony. This should rather be handled in Symfony and used by Doctrine.
|
|
@vicb Symfony already depends on Doctrine Common for the annotation part so we could rely on it for the caching part. Otherwise, we would have a yet-to-be-written Symfony cache and a Doctrine Cache along it for Doctrine. And this would not be a unified cache :) |
|
@stof the idea would be to use doctrine common for the low level cache drivers but I still think the bundle should be handled by Sf and could provides more functionality that what is strictly needed by Doctrine. (But yes we should also probably consider having a "Symfony cache" with some kind of adaptors for Doctrine during the design phase) |
|
Where are we on this issue? I believe this is an important point to deal for the 2.1. |
|
On my side I haven't made of lot of progress (except a few PRs against doctrine common) My vision ATM:
Why cache factories ? Should we use the drivers from Doctrine2 ? The bundle from Liip is probably a good starting point. Ideally in the config That is my POV. |
|
@winzou May be the more important is that somebody start something, what about you ? |
|
I very much like that plan and I am totally ok with retiring LiipDoctrineCacheBundle once this is all in place. Especially I share the sentiment that we need factories (even for just Memcache(d) instances) so that we can then use these in any other bundles instead of having to duplicate the code to build the instances all over the place as we do now. |
|
Maybe we can create a Cache Component instead of bundle. The Cache component will be independent and usable in any other non-Symfony2 project as other Symfony Components are now. |
|
+1 for @pulzarraider idea. Having something like a Cache component that would also allow for adding new types of caches would be great. I'm thinking to start with it should allow for these types of cache formats:
It should contain the basic methods for all the classes: Maybe also it should have some sort of console command interface so that you can run all the above functions from cli directly. I'm not sure how to exactly start on this but if you all agree with the above I could give it a try next week and possibly make a PR by the end of 5th February. |
|
@pulzarraider @dlsniper what about using doctrine common for now and focus on the bundle ? (see my previous msg) |
|
@vicb I was taking into consideration this comment: #1513 (comment) |
|
Changing a namespace is not a problem, re-develop a working solution is a waste of time. |
|
I know, I’m gonna be beaten but why not use Zend\Cache\Manager? It’s supports a wide variety of adapters, has support for tagging and we would only need a few bridges implementing package specific interfaces (e.g. for Doctrine). |
|
I will be happy to merge/refactor the SonataPageBundle's cache handler, however there is a missing feature in the current thread : contextual information. A cache can have :
I guess the LiipDoctrineCacheBundle and SonataPageBundle's cache code can be merge/refactored to match our need. |
|
The question with Zend\Cache\Manager is how decoupled it really is. |
|
Imho Symfony should provide its own Cache interface in the Components (HttpKernel?), like with logging and have no implementation on its own. If its looking like the Doctrine interface or even simpler then we could easily have a Doctrine wrapper in FrameworkBundle, as that already depends on Doctrine Common anyways. We could then move LiipCacheControlBundle into FrameworkBundle. It makes much more sense in the core than in Doctrine org. Only this way we get it unified. |
|
Closing as we will not do anything before FIG agree on a cache interface that we can leverage. |
The doctrine bundle, the validator and the annotation reader all support caching.
The doctrine bundle supports memcache, apc, array and xcache.
The annotations reader supports file and any mechanism that implements
Doctrine\Common\Cache\Cacheby providing a service in the configuration.The validator component only supports apc.
It would be great to be able to define some cache providers in the framework configuration and use them from the configuration of those 3 components.
That would require changing the configuration of the doctrine bundle and the annotation reader and implement a ClassMetadataFactory that would use an instance of
Doctrine\Common\Cache\Cache.The text was updated successfully, but these errors were encountered: