bug: KeyvRedis key prefix namespace behavior is not consistent with Keyv (core)
titanism opened this issue · comments
Duplicate of jaredwray/keyv#700. This applies for other adapters besides Redis. The default behavior should match the behavior that comes out of the box in core Keyv regarding namespaces and key prefixing. Otherwise you run into having to create multiple connections because ioredis does not support that (see redis/ioredis#983).
It would be helpful to have notices as to what makes this repo different than @jaredwray's. It says this one is maintained, but there are recent commits to that repo too.
In any case, I'd love to have contributor access on GH and npm so I can help fix this stuff. I use np for version releases and abide by semver.
On a side note, I see some improvements already, e.g. jaredwray/keyv#699 was already implemented:
@titanism - this is a fork of the the main Keyv and causes confusion with many. We are also planning a fully rebuilt redis coming in the next 2-3 months on the main Keyv repo.
Thanks @jaredwray. 2-3 months isn't feasible for us - or we'll end up forking this package or making our own - is there any way we can get access to Keyv repo and help maintain? We ship code pretty quick and high-quality with tests. Not sure if you've seen tangerine but we shipped that in 5 days.
Happy for you to contribute changes anytime and we review changes as fast as we can. We usually release very 10-14 days.
Nevermind about access - we'll probably just switch Tangerine off of Keyv due to all these issues and let the user decide what to use for implementations.
Thank you though so much @jaredwray 🙏 🙇
@titanism - note this thread is on a forked version of keyv. Lets keep any requests or concerns on the main repo here: https://github.com/jaredwray/keyv
Hum, It sounds a bit strange to me. I'm reusing Redis instance in my current project setup.
Can you isolate the bug into a reproducible repo or test? then could be easy to fix it.
In fact, I reported that years ago: jaredwray/keyv#102
That's one of the reason we decided to forked it and take care.
What was actually buggy is the example on docs; Now it should be reflected how to reuse Redis instance properly.
Also, I re-wrote the test in a more readable way to showcase how the store is reused:
Thanks for reporting, @titanism 🙂
This is still an issue. The namespace is not being used for setting key prefix as Keyv does out of the box as linked here https://github.com/microlinkhq/keyv/blob/69f95c41789d2a7fb83fbcc80e120e9f2a15274c/packages/redis/src/index.js#L35-L38 versus https://github.com/microlinkhq/keyv/blob/69f95c41789d2a7fb83fbcc80e120e9f2a15274c/packages/core/src/index.js#L53-L62.
I think that all packages, not just Redis adapter, e.g. Mongo, etc should all have this same consistent behavior. If you set a namespace, then it's used as key prefix too. Perhaps a configurable option for each as well useNamespaceForKeyPrefix: true by default?
@Kikobeats please re-open this issue
The implementation can differ between connectors, since every connector has different constraints.
It should be consistent, otherwise these tests would break
https://github.com/microlinkhq/keyv/blob/master/packages/test-suite/src/namespace.js
and all of them are passing green:
https://github.com/microlinkhq/keyv/actions/runs/4281342167/jobs/7454247122
Can you write an assertion there that demonstrate it isn't working consistent? Then I will be happy to re-open the issue.
@titanism - if you are planning to use the microlinkhq version please work with Kikobeats on it and work in this repo and issues and you can leave me off.
As mentioned in jaredwray/keyv#700 (comment) due to the same issue in both packages, I will not be using Keyv (either package) in Tangerine. But thank both of you for your contributions to open-source software and pushing the bar!