-
Notifications
You must be signed in to change notification settings - Fork 71
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
Caches not expiring #73
Comments
There are two types of data you can pass to
In the former case, the item ttl is the "global" ttl (provided to So I think it would work if you used the 1st approach (provide just the raw value). The 2nd option is meant to be used if you want to override the default cache ttl. If you prefer passing the item, then I think setting |
Thanks for the quick response and explanation. I adjusted the code to use a plain value and now everything is working as expected. A couple of suggestions:
I realize 2. might involve a breaking change so may not be worth it currently, but I would be happy to open PRs for both of these on your advice. Thanks again! |
Yeah, it's kind of there, but not obvious. The first few examples use It's also worth noting that this duality in the specs (https://hexdocs.pm/con_cache/ConCache.html#put/3), but the function docs are missing, so the difference is again not clear. I agree that we should make this more obvious, at the very least in README. We should perhaps use some concrete value in the first set of examples. Then in TTL examples we could have an explicit sentence which explains that item struct can be passed for fine-grained TTL control.
Yeah, I think making this field required would be the best option. It is a breaking change, but at least it will break compilation, instead of causing non-obvious behaviour change. TBH, looking back, I don't like the existence of But that said, I'm fine with a simpler PR which improves the readme and requires item ttl to be explicitly set. |
I have a few relatively simple caches that look like this:
The active_users_cache just contains a user id and a timestamp (their latest request), added like so:
But AFAICT, it's never expiring. When I inspect the ets table I see entries like this:
My understanding would be with my ttl settings I should never expect to see 2 entries more than 70 secs apart since the
put
should overwrite the last value, meaning the timestamp should reflect the last time the ttl was set.Aside from exp the values all look correct and it works as expected.
Is there anything obvious I am doing wrong? What is the recommended way to go about troubleshooting this?
The text was updated successfully, but these errors were encountered: