That's great, thanks. I would have cloned the object myself otherwise, but this way it's better.

If I may add one last question: I have a use case where a Keyv instance backed by a store that doesn't support TTL functionality (memory, sqlite) would grow indefinitely (because keys aren't deleted proactively unless, you know, one uses Redis or something like that). That's because data would make it into the cache once but would never be getted again, leaving the memory / disk space occupied.

I understand that iterating over the entire store on Keyv's side would impact all of the namespaces, so some filtering of the keys would be necessary. Doing this filtering in a store-independent way would be probably impossible.

Moreover, there's no way of avoiding getting each and every cached item in the current namespace in order to look at the expiration time; so the only reasonable way of doing a sweep would be to have Keyv also keep a chronologically sorted list of keys and expiration dates that could be used to cut down on the performance impact at the expense of a bit more memory. This part could be disabled by default and enabled on demand, but still, it's quite a bit of code.

Given all this, is a cleanup function of sorts worth figuring out and including in Keyv? If you're open to the idea I can work on a pull request, but this is a magnificently simple module and I'd understand if you'd rather not impact it with something so intrusive. The alternative - the user bites the bullet and just calls get on every key periodically - is not unacceptable, after all. So before acting, I thought I'd just ask for your opinion.

Are in-memory cache values accessed by reference #15

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions