Feature requests

[philippgille]

This is a general thread for feature requests. Maybe some of the feature requests initially discussed here will turn into their own discussions later.

[GwynethLlewelyn]

*coughs*, well, so let me get started on the first one...

Soooo quoting myself...

I'd love to see the (suggested)List()/GetAll() method to retrieve all keys :-) I know that's a bit beyond the purpose of the simplistic (but effective!) API, and could/should be delegated to a higher level, but the truth is that I'm completely stumped at how to implement that using the current API (granted, I'd need a few more things, namely, the ability to retrieve only a subgroup of keys, according to some simple criteria, or not-so-simple ones such as a nice regexp, but that's ok, for my purposes, I can do that in memory). And sure, I agree with your suggestion that the 4 basic primitives would be at the core of the SimpleStorage object, while additional goodies would be part of an AdvancedStorage object. That totally makes sense to me — especially because some backends (such as Redis or in-memory storage) would possibly work with am AdvanceStorage, but others might only be able to work with a SimpleStorage. Having both options sounds like an excellent solution!

To recap:

1. Add support for a method (List()/GetAll()) that retrieves all keys currently held in the database:

• just retrieve them all in no particular order (i.e. whatever the 'best' transversal algorithm might be)

• or using a simple search (just all keys starting with, say, my-domain-key)

• or even allowing a regexp (assuming that such a functionality can be implemented at all for the many possible KV stores...)

• or use XPath/CodeQL as a query language (I'd guess that would be overkill)

  Obviously, such options could also be left for users to implement on top of List() and not be part of gokv at all...

2. Add support for retrieving just the first N keys

   Here I'm thinking about stores holding millions of keys, where it might make more sense to retrieve just N keys and some sort of pointer/marker/cursor to key N+1 to be retrieved on the next call

3. Leave the core functionality of the 4 primitives as a standard for a SimpleStorage object, and implement List()/GetAll() and everything else as an AdvanceStorage object — this would allow the two to be independently developed (I'm thinking of the ability of directly providing such functionality at the layer beyond — while most KV stores have something like that, perhaps not all have such an option, which would require additional development).

[glimchb]

to avoid major break and support backward compatibility, added WithContext functions for get/set/delete #136
feel free to comment and review this is a draft

[philippgille]

I'm still undecided between a hard breaking change vs. adding the new methods to the interface (or a separate one) vs just adding them without changing the interface.

Currently I think the requirements for the next version are the ones mentioned in #159 (comment), and any bigger changes like the context can come in the next version.

I'd also like to hear more opinions about the context approach from more library users. Maybe @shawncatz as you recently created the other thread?

[glimchb]

WDYT @philippgille if we keep interface unchanged until you decide, but add new function for each implementation with context ?
will that work ? I can rebase my change or create a new one... let me know...

[shawncatz]

I'd also like to hear more opinions about the context approach from more library users. Maybe @shawncatz as you recently created the other thread?

Hi, I guess I would lean towards having a separate ...WithContext interface that a user to could migrate too and then adding deprecation notices to the older impl functions.

For my use case, it wouldn't be a significant lift to cut this over if the change to WithContext were more abrupt, but I'm guessing it might impact others more significantly.

[glimchb]

@philippgille congrats on the new release! what is the decision on Context ?

[philippgille]

Yesss 🙂

Let's go with implementing the context arg in additional methods for now. This allows to go store by store, having each in master already, and in case we need to do a new release while not all stores are migrated yet, the old interface and all stores would still work. If all stores are updated with the context methods, then we can still choose to make a hard cut before a release. But for now it leaves us more flexibility to go with the additional methods while keeping the old interface.

🚀