SRFI-167 OKVS
I see that okvs-ref instead of okvs-get is to be consistent within scheme, but I’m struggling to find another egg that uses *-rm as a function name. Copying from hashtable, is *-clear or *-remove more standard?
I also notice that you’ve elided range clears entirely from your API. Was that intentional? They are inconsistently supported across kv stores…
CONFIG might contain the following options:
key description … … 'isolationa symbol among 'read-uncommited,read-commited,snapshot.
Be careful about using the ANSI definitions of isolation, as they don’t map cleanly to anything that’s not a single-version pessimistically locked database. See A critique of ANSI SQL Isolation Levels and Generalized Isolation Levels.
I feel like isolation is something you’d be better off leaving out of the SRFI. Which you kind of did already, as it’s in an optional config struct.
(okvs-transaction-commit transaction config)
Various transaction APIs disagree on if transactions need to be explicitly committed or aborted, so you’d probably want to be conservative, and mandate in the SRFI that you must commit or roll back any started transaction.
(okvs-range some start-key start-include? end-key end-include? [CONFIG])
SOMEcan be aokvsortransactionobject. This procedure should be decorated with with okvs-transactional.
The only difference between an ordered and unordered key-value store is if it supports efficient range operations. If your SRFI requires arbitrary get-ranges, you’re going to require someone to write an almost-equivalent unordered key-value store SRFI, and you also technically ban systems like Cassandra that distributes data such that a known prefix of the key is randomly distributed and a suffix of the key is sequentially distributed.
(okvs-transactional proc) -> procedure
I’m happy to see that your proposal includes a transaction runner, but I don’t recall seeing “decorator” be a common scheme pattern? I feel like I see explicit transaction runner functions in most other language’s database bindings. You could just offer a function like (okvs-run okvs proc), and then (okvs-run okvs (lambda (db) (okvs-ref db key))) would be equivalent to the current ((okvs-transaction (lambda (db) (okvs-ref db key))) okvs), the latter of which I find harder to mentally parse.
That said, I have enjoyed @fdb.transaction making life simple in the python bindings, and I don’t really have a great sense of what is or is not idiomatic for scheme anyway.
SRFI-168 Tuple Store
I don’t have any additional comments on this, other than, could you provide an example of nstore-from → nstore-where chaining with nstore-select. My brain is breaking slightly trying to understand this generator of bindings getting manipulated.