10 suggestions for improving keyvalue api about interfaces HOT 7 CLOSED

This issue should be in the Interfaces repo instead of wasmcloud-otp

from interfaces.

Wondering if maybe we should make these changes, but do so under a new contract ID called wasmcloud:keyvalue:v2 ? I know there aren't many people actively using these providers in the 0.18.x space, but for consistency we should honor contract versioning given that this would be a large breaking change.

Opinion wise - I suggest we not implement anything that queries keys. There are a number of key-value stores where access to the list of available keys/keyspace is not possible. Even in Redis where it's possible, it's difficult to do without blocking the entire database (you need to use a "key cursor" rather than running the KEYScommand)

from interfaces.

a new contract ID called wasmcloud:keyvalue:v2

yes it would need a new contract id

it's difficult to do without blocking the entire database (you need to use a "key cursor" rather than running the KEYScommand)

You need a key range request for a lot of object schemas, for example, if employees are keyed with "employee.LAST_NAME.FIRST_NAME", the way you query all employees is starting at "employees."

All range requests should be paginated. the range request api would contain a start key, optional end key, and a limit number. The limit number is just advisory - the provider can return any number up to (but not greater than) the requested limit number. The provider can set a limit number low enough to make it effectively non-blocking. Each response returns a watermark token that would be the start-value for the next range request.

from interfaces.

Redis, IIRC, doesn't support key range queries out of the box, so the provider would actually have to create some kind of secondary index to manage this or worse, get all keys and then do the range filtering in memory in a loop.

from interfaces.

Scratch that, looks like you can accomplish a range query in Redis by using a match clause inside a sscan, e.g. sscan myset 0 match f*

from interfaces.

document clarification (for a future revision of this interface):

to allow an implementation to use separate "keyspaces" for different data types, (kv, list, set, and counter), if the same key is used in different keyspaces, the results are undefined. For example, if list-add ("foo", "x") is followed by get("foo"), the get() may return a value, or None, or an Error. Another example: for the operations list-add("foo", "x"), set("foo", "y"), list-clear("foo"), get("foo"), an implementation may return either Some("y") or None.

To accommodate separation of keyspaces, it may make sense to expand some of the existing apis:
del -> del (for kv), del_counter, del_list, del_set
contains -> contains, contains_counter, contains_list, contains_set

and add: set_counter, get_counter, because kv methods may not work to initialize the counter to a non-zero value, or to non-destructively read the value.

from interfaces.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this has been closed too eagerly, please feel free to tag a maintainer so we can keep working on the issue. Thank you for contributing to wasmCloud!

from interfaces.