search

eko / gocache

☔️ A complete Go cache library that brings you multiple ways of managing your caches
https://vincent.composieux.fr/article/i-wrote-gocache-a-complete-and-extensible-go-cache-library/
MIT License
2.42k stars 192 forks source link

store.Options does not expose its props, making StoreInterface challenging to implement #191

Closed RoxKilly closed 1 year ago

RoxKilly commented 1 year ago

Steps for Reproduction

The docs suggest that the dev can use a custom store by implementing the StoreInterface. I'm working on a custom cache to use as part of the library's chain cache but one sticking point is the Set. Here is its definition:

Set(ctx context.Context, key any, value any, options ...Option) error

Option is a function that takes and configures an Options object, both from the library package. here is how the library passes it to my cache's setter: github

Within the library's cache implementations, the configured Options object is then read to discern, for example, the expiration date of the cache entry: example

The issue I face is that Options (declared here) makes all its properties private, so when I implement my own Set(), I have no way to read it to figure out when the cached entry should expire.

How is my custom StoreInterface implementation supposed to figure out the caching options used?

Expected behavior:

Custom struct implementing StoreInterface can be used in the chain cache

Actual behavior:

Unable to implement interface correctly because the Options object passed to my implementation does not expose the options in public properties

Platforms:

All

Versions:

v3.1.1

RoxKilly commented 1 year ago

I cloned to open a PR and noticed that this has been fixed in the master branch. However it hasn't been released to v3 yet (v3.1.2 has the same issue). Is there a plan to release this change on the v3.x version?

Is the intent to require users to move their codebase the v4 releases to be able to implement StoreInterface?

RoxKilly commented 1 year ago

I think the change is small enough that releasing it as a v3.x would probably be worthwhile for teams that face a lot of friction whenever they want to upgrade a dependency to the next major version. That said, feel free to close the issue if upgrading to v4 is the intended fix.

Thanks

eko commented 1 year ago

Hi @RoxKilly,

Sorry about the delay but yes, the actual fix has been done into the v4 release.

If you really need it, I can add the fix in v3 and make a new patch release.

I close this issue for now but feel free to reopen and tag me if you need it.