wasi-keyvalue icon indicating copy to clipboard operation
wasi-keyvalue copied to clipboard

Non string keys

Open olanod opened this issue 3 years ago • 5 comments

There are many use-cases that would benefit from having a key-value store where keys are not strings but opaque bytes, would there be a particular reason why the type key needs to be string?

olanod avatar Apr 08 '23 21:04 olanod

I have experimented with a few keyvalue stores (dynamodb, redis, azure cosmos db) and they all seem to accept key as strings. Could you please list a few use cases where the keys are non-strings? I am happy to change the key type

Mossaka avatar Apr 12 '23 23:04 Mossaka

I'd use it for embedded use cases for example, sometimes directly store the bytes or abstract it to use data structures that are encoded automatically to an efficient representation.

olanod avatar Apr 15 '23 08:04 olanod

Another challenge with byte sequences is that it's not possible to transcode plain bytes to key-value stores which use different character encodings. It looks to me like string is a better fit for the use cases and implementations that originally motivated wasi-keyvalue.

sunfishcode avatar Apr 21 '23 01:04 sunfishcode

What about supporting both with keys being something like an enum?

olanod avatar Apr 21 '23 07:04 olanod

With an enum, using wasi-keyvalue with a backend that needs strings would have to always fail when given bytes.

Could you say more about your use case? What kinds of embedded programs would use an external key-value store? What backends would you expect to be used to implement the interface?

sunfishcode avatar Apr 21 '23 13:04 sunfishcode