Expose more raw Keyv functionality to enable better extensions.

If Keyv (and official storage adapters) were to expose more internals, this would allow for much richer functionality to be built on top of Keyv.

Mainly:

• Optionally return the raw DB object (#39)
• Get all keys method (#40)
• Delete multiple keys in a single operation (#41)
• Get multiple keys in a single operation (#78)
• Check if key exists (#50 )

Main thing that comes to mind is a DB migrator (needs access to expiry dates) and keyv-shrink which is currently a fork because the desired functionality couldn’t be implemented on top of Keyv.

With the three listed options implemented, keyv-shrink could be implemented efficiently on top of Keyv. All updates to Keyv and Keyv storage adapters would automatically work with keyv-shrink. Example of an implementation could be something like this:

const Keyv = require('keyv');

class KeyvShrink extends Keyv {
  shrink() {
    ...
  }
}

@MySidesTheyAreGone What are your thoughts on this? I’m tied up on client project right now but I’m interested in adding this soon.

[ghost]

Yeah, ok:

I was thinking adding .keys(), .values() .entries() methods similar to the Map spec but instead they would return a Promise that resolves to an iterable.

This is even more than I need, so no worries.

In the meantime enjoy a bit of science fiction (stage 3 proposal):

https://github.com/tc39/proposal-async-iteration

[ghost]

Defining Symbol.iterator in Keyv’s class:

  * [Symbol.iterator] () {
    yield* this.opts.store;
  }

I can now do this:

> var Keyv = require('./src/index.js')
> let test = new Keyv()
> test.set('one', 1)
> test.set('two', 2)
> test.set('three', 3)
> for (let item of test) {console.log(item)}
[ 'keyv:one', '{"value":1,"expires":null}' ]
[ 'keyv:two', '{"value":2,"expires":null}' ]
[ 'keyv:three', '{"value":3,"expires":null}' ]
undefined

This only works if the store is a Map, of course. To make it work on everything we need to implement [Symbol.iterator] in the other stores, which may or may not be difficult.

If we do make it work, it would be enough for a slower but compatible version of shrink() (right now it defines one more column) and keyvrator (which always goes through all of the keys anyway). Probably make a lot of other things possible too.

I don’t know, food for thought.