Skip to content
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

Support polymorphic keys #355

Open
cb372 opened this issue Feb 18, 2020 · 3 comments
Open

Support polymorphic keys #355

cb372 opened this issue Feb 18, 2020 · 3 comments

Comments

@cb372
Copy link
Owner

cb372 commented Feb 18, 2020

Currently we only support String as a cache key. This makes sense for remote caches such as Redis and Memcached, where the key needs to be a bytestring, but is unnecessarily limiting (and slow) for in-memory caches such as Caffeine.

I'd like to update the API to support any type K as a cache key.

Things to consider:

  • We need a way to turn a value of type K into a representation type that the cache implementation can handle:

    • Memcached needs a String
    • Redis needs an Array[Byte]
    • Caffeine needs a K, assuming K has a sensible equals and hashCode

    Probably a KeyEncoder[K, Repr] type class would make sense here. e.g. RedisCache[K] would require a KeyEncoder[K, Array[Byte]].

  • The memoize macro generates a String key, e.g. myFunction(123, "abc"). So it will only work with caches that accept String keys.

  • The API currently accepts keyParts: Any*, calls toString on each part and concatenates them together using a configurable separator. I'm not sure how useful this feature really is. Probably better to just take key: K and stop messing around with varargs and toString.

@lewisjkl
Copy link
Collaborator

Love the idea of getting rid of keyParts in favor of a KeyEncoder type class.

Are you thinking that we will also provide auto/semi-auto derivation for instances of that type class? I’m guessing that it’s something we’d want to do, but also may be out of the scope of this issue and we could revisit after we finish this one.

Sent with GitHawk

@ronnnnnnnnnnnnn
Copy link
Contributor

Hi,
I've used ScalaCache on my last job and was also wondering about the the lack of an ability to have non-string keys. I have been thinking of maybe contributing a little bit once I have some free time on my hands, which I do now.
I'd be happy to take a stab at this one, if that's okay.

* The `memoize` macro generates a String key, e.g. `myFunction(123, "abc")`. So it will only work with caches that accept String keys.

I'm thinking the cleanest way to do that might be to take the memoization methods out of the main trait hierarchy and separate them to some side trait that could be used as some sort of decorator when memoization is wanted and the key type is string, maybe as a self type. What do you think?

@ronnnnnnnnnnnnn
Copy link
Contributor

Made a pull request with my changes, I hope it's alright. Let me know what you think.
#565

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants