batch::get-many should parallel store.get

[devigned]

get: func(key: string) -> result<option<list<u8>>, error>;

in store returns an option<list<u8>>, but

get-many: func(...) -> result<list<option<tuple<string, list<u8>>>>, error>;)

in batch returns list<option<tuple<string, list<u8>>>>. I would expect get-many to return result<list<tuple<string, option<list<u8>>>>, error>;.

[Mossaka]

this makes sense to me.

Since this updates the APIs, can you bump the draft version up?

[Mossaka]

Can you please update the docs for get-many?

/// get-many returns the key-value pairs associated with the keys in the store. It returns a list of
/// key-value pairs.
/// The returned list of key-value pairs must have the same length as that of the `keys` parameter.
/// If any of the keys do not exist in the store, it returns a (key, `none`) value for that pair in the list.

[thomastaylor312]

I can go either way on this. I think we may have had it the way you have it in this PR before, but I swapped it out because you have to return a copy of the key. For a batch request, that means even if you have no data to show, you have to return a new key (which could be quite large for some people). Since batch requests are big, this is where extra allocations of keys could matter. I swapped it to the option because it should be returned in the same order as passed in, so if you absolutely need to know which key you need, you can refer to that. Here are our options and the tradeoffs:

What you have in this PR:

list<tuple<string, option<list<u8>>>>

Advantages: Easiest to consume because you have each KV pair
Disadvantages: Extra allocation of every key that is passed in

Current:

list<option<tuple<string, list<u8>>>>

Advantages: No extra allocations of non-existent keys
Disadvantages: Awkward mapping back to initial list of keys if you need to know the missing key

Option 3

list<option<list<u8>>>

Advantages: No extra allocation of keys
Disadvantages: Required iterate over the list of keys and results together (which can be awkward/annoying in some languages)

So I think those are the options. After putting some thought into it here, I'd rather have option 3 to avoid all sorts of extra memory usage (and copying), but we should decide together what we'd prefer here