Comments (4)
This change causes tests/ut/test_base.py::TestBaseCache::test_alt_build_key_override_namespace[None-key] to fail: (
AssertionError: assert 'test:key' == 'key'
). This makes sense because the namespace gets overridden byself.namespace
before the customkey_builder
gets called. The strange part is that I think this test should have already failed before I made these changes.
Oh, right. That's because this test is making a bare call to build_key()
, rather than going through one of the other methods (add
/set
/get
/...). In the main branch, a custom key_builder
has the ability to (optionally) override the namespace logic (including default value) of the cache. The changes in this new branch put that control back to the cache, so that the only way to override the cache's default namespace is to provide an explicit namespace when calling BaseCache.build_key()
.
My hunch is that this will break the ability to override the default namespace in a cache decorator that is backed by an alias
cache, and have a similar effect on other classes that don't explicitly accept namespace arguments (like RedLock
). Currently I have a project that relies on being able to override the namespace in this scenario.
I'll need to look into how best to resolve this.
from aiocache.
My hunch is that this will break the ability to override the default namespace in a cache decorator that is backed by an alias cache, and have a similar effect on other classes that don't explicitly accept namespace arguments (like RedLock). Currently I have a project that relies on being able to override the namespace in this scenario.
After preliminary review, I think it will be ok to proceed as started in this branch.
The other project I mentioned subclasses the cached
decorator class to create a new alias cache on the fly with the desired custom BaseCache.build_key()
override. So this works with these new changes.
Regarding the RedLock and backend implementations, even where namespace is not explicitly provided, I think it makes sense to fall back on the cache's namespace
member. Otherwise it would probably be better to use a different cache object for those edge cases where a different namespace is needed.
This change causes tests/ut/test_base.py::TestBaseCache::test_alt_build_key_override_namespace[None-key] to fail: (
AssertionError: assert 'test:key' == 'key'
).
I'm inclined to modify this test to remove this pathological behavior, where a custom build_key
uses a default namespace that does not match the cache's default namespace (i.e., the value of its namespace
member).
TL;DR I'm moving forward with the originally suggested changes.
from aiocache.
Yes, I think we want to have the default namespace, so changing this behaviour seems fine. The test should still pass in the 3rd paramater, where a non-empty namespace is used.
We could also consider checking for None
for the default namespace and allowing an empty namespace with ""
, if there's still some desired behaviour for that.
from aiocache.
from aiocache.
Related Issues (20)
- Issue with typing in v0.12.0 HOT 6
- Implement .all() method. HOT 2
- BaseCache should be ABC HOT 2
- Remove factory
- Tests folder being imported when installing version 0.12.0 HOT 1
- Merge cache implementation classes for each backend
- Library is unusable with redis older than 4.2.0 installed, even if redis isn't used HOT 2
- Type issues with VS Code + aiocache HOT 1
- Make it possible to run tests with a subset of dependencies HOT 5
- Cache key based on "self" in @cached decorator might not always be unique HOT 1
- [Question] Reuse decorator settings + Race Conditions
- "No module named 'redis.asyncio'" when trying to build with docker HOT 1
- Passing username to Redis in decorators HOT 1
- Redis cache decorator fail on Python3.11 HOT 2
- Create Multiple caches HOT 3
- New release HOT 1
- Preserve function signature with decorator HOT 3
- set_cache default does not work with plugins HOT 2
- Unsupported operand type(s) for +: 'float' and 'SimpleMemoryCache' HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from aiocache.