Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[WIP] Namespaced cache decorator#96

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
Tobion wants to merge2 commits intodoctrine:masterfromTobion:namespaced-cache-adapter
Closed

[WIP] Namespaced cache decorator#96

Tobion wants to merge2 commits intodoctrine:masterfromTobion:namespaced-cache-adapter

Conversation

@Tobion
Copy link
Contributor

The idea is to implement namespaces using a decorator. This makes much more sense than having namespaces built-into the generic CacheProvider because namspaces only make sense for shared caches. So non-shared caches like ArrayCache should not have namespace logic at all.

Also the need to add namespaces depends on the usage. If a developer uses a global cache like Redis but does not reuse it it many unrelated places (where he cannot ensure cache ids do not collide), there is no point in adding namespaces. This also has the benefit to not add the overhead when not needed. The current overhead comes from reading the namespace version on each fetch. So currently each fetch does two accesses. The version is cached in the CacheProvider to boost the performance, but that can obivously result in race conditions. So this is removed in the decorator.

Decorating a cache with this namespace logic will also make sure that deleting all cache entries usingflushAll() will only remove the cache entries of the given namespace and not everything. This way one application/library can delete all of its cache without interfering with the shared cache of another app/library. This makesClearableCache::deleteAll obsolete. Classes that use a cache should not have to care aboutdeleteAll vsflushAll. They just want to delete the stuff. It's the task of the developer to make use of the namespace decorator when they have a global cache and different places where deletion can occur.

Todo

  • Throw exception if decorated cache doesn't implement MultiGetCache or FlushableCache
  • Add tests for decorator
  • DeprecateCacheProvider::setNamespace andCacheProvider::getNamespace. In the next major version we can then remove namespacing from there and thus the cache providers that don't need it like ArrayCache will not by default inherit the namespace overhead.
  • Updatehttps://github.com/doctrine/DoctrineCacheBundle to use NamespacedCacheDecorator when anamespace config is used
  • Updatehttps://github.com/doctrine/doctrine2 to only useflushAll (ordeleteAll if we want to settle on this name). This is mainly used in cache clear commands.

gskema reacted with thumbs down emoji
@andrerom
Copy link

Nice to see this being moved out.
Any chance drivers will be refactored to only implement the interfaces they support as part of this?as opposed to everything via an abstract

@andrerom
Copy link

Strike that, for bc cache provider will need to implement all anyway, so besides moving names spacing out it can stay as is.

@OcramiusOcramius added this to the1.6.0 milestoneOct 28, 2015
…limited to the current namespaceSo the decorator just overwrites flushAll. There should not be two methods (flushAll and deleteAll) for the same thing.
@Tobion
Copy link
ContributorAuthor

I had another idea which would also make the decorator obsolete.

CacheProvider can accept aCacheIdNamingStrategy interface. We can then provide different implementations of it, e.g.HashedCacheIdNamingStrategy,TransparentCacheIdNamingStrategy (not modifying the cache key) andNamespacedCacheIdNamingStrategy.

This would solve another problem at the same time: Currently the allowed cache ids are based on the used adapter. E.g. Memecached does not support whitespaces whereas others caches do. So if people would have to deal with special chars, they can just inject a hash strategy and are set whatever cache adapter they will use.

@OcramiusOcramius removed this from the1.6.0 milestoneDec 30, 2015
@TobionTobion mentioned this pull requestJan 28, 2016
@andrerom
Copy link

Time to move this forward? With symfony cache using this now it would be good to be able to avoid this overhead one way or another(for me it is ;)). personally I prefer decorator approach as it then doesn't add any cost when turned off at all.

And special rules on cache id's either needs to restrict interface of all, or be normalized in specific adapter imo. Forcing user to match correct name strategy service with adapter is asking for mistakes to happen.

@yellow1912
Copy link

Any hope for this to be rolled out anytime soon? I need to save to redis in my application but then retrieve from other place. (lua code). The versioning is messing up the expected key.

@yellow1912
Copy link

@Tobion I think your idea with CacheIdNamingStrategy can work really well. We can then easily support the configuration in DoctrineCacheBundle as well, by specifying the naming service we may want to use.

@Tobion
Copy link
ContributorAuthor

Closing as I don't have intention to finish this one.

@TobionTobion closed thisOct 28, 2018
@TobionTobion deleted the namespaced-cache-adapter branchOctober 28, 2018 19:02
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@Tobion@andrerom@yellow1912@Ocramius

[8]ページ先頭

©2009-2025 Movatter.jp