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

Time To Live #18

Closed
Solido opened this issue Aug 18, 2019 · 6 comments
Closed

Time To Live #18

Solido opened this issue Aug 18, 2019 · 6 comments

Comments

@Solido
Copy link

Solido commented Aug 18, 2019

I'd like to use Hive as a temporary cache for resources.

Setup would be done with a TTL field that can be set at the Box and write method level.

box.putAll({'key1': 'value1', 42: 'life'}, ttl: const Duration(seconds:30))

Is this a feature in the scope of Hive ?

Thanks

@simc
Copy link
Member

simc commented Aug 18, 2019

This is a very good idea. I don't know if it is possible but I'll think about how to implement this.

@Solido
Copy link
Author

Solido commented Aug 18, 2019

I've tinkered with something like this :

class Ephemere {
  final Duration defaultDuration;
  final Map<Object, dynamic> _cache;

  Ephemere(this.defaultDuration) : _cache = Map();

  dynamic get(Object key, Function defaultValue) {
    final rs = _cache[key] ?? defaultValue();
    return rs;
  }

  Future put(Object key, value, {Duration duration}) {
    Completer completer = Completer();
    _cache.putIfAbsent(key, () => value);

    Future.delayed(duration ?? defaultDuration, () {
      _cache.remove(key);
      completer.complete(value);
    });

    return completer.future;
  }
}

@simc
Copy link
Member

simc commented Aug 18, 2019

Yes that looks promising but how would you handle a TTL greater than the runtime of the app?
It would need to be persisted and checked when the app is started again.

@Solido
Copy link
Author

Solido commented Aug 18, 2019

Correct, Also I'm not sure this approach is the best when you have a huge numbers of keys ...
If you have a hash you can have an external manager with timestamp, seems more efficient.

Completers would resume on the diff time now and previously calculated expiration timestamps.

@simc
Copy link
Member

simc commented Aug 18, 2019

Correct, Also I'm not sure this approach is the best when you have a huge numbers of keys ...
If you have a hash you can have an external manager with timestamp, seems more efficient.

I agree...

Completers would resume on the diff time now and previously calculated expiration timestamps.

Could you please explain that? I don't understand what you mean exactly.

@simc
Copy link
Member

simc commented Sep 1, 2019

I'm going to close this for now. I think a external solution would be easier to implement...

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

2 participants