Amirouche Boubekki, author of SRFI 167: Ordered Key Value Store
and SRFI 168: Generic Tuple Store Database, has asked me to
announce "last call" for both SRFIs. He believes that they are
ready for finalization, but would like to give reviewers one last
chance to submit corrections and feedback before we finalize them.
Editorial issues:
1. The terms "must" and "should" (and "may" and "required" and "recommended") are applied only to the implementation, not to the user or to a program. So "must be an association list" should be replaced by "It is an error if this argument is not an association list." Likewise, "This procedure should be decorated with with okvs-transactional" should be replaced by something explaining the consequences if it is not.
2. The name "okvs-rm!" should be "okvs-delete!" The difference between "delete", "remove", and "clear" is as follows: "delete" removes a specific element by key ("delete-all", if provided, takes a list of keys, but it does not have to be provided). "Remove" removes elements that satisfy a predicate. "Clear" removes all elements. So "delete!" is correct here. I also agree with FoundationDB that "range-remove!" is an important part of the API. If a particular database does not support it, it is easily implemented in Scheme.
3. "Read-committed" and "read-uncommitted" are spelled with two Ts (but consider the objections from FoundationDB).
Substantive issues:
1. I think the "home" config option should be (a) required from all implementations and (b) an error to omit from the config list (which therefore becomes a mandatory argument). It is very improbable that there is exactly one database in a system, not to mention the possibility of remote databases identified by URL.
2. Likewise for 'read-only?' and 'create'.
3. The lexicographically smallest key is zero bytes long, but the lexicographically largest key depends on the maximum size of a key for the particular database implementation. For example, on FoundationDB it is a bytevector containing 10,000 0xFF values. So to read 'from key K to the end', there needs to be a procedure `(okvs-maximum-key okvs)` that returns the largest possible key and says that it is an error to mutate this key (that way only one is needed for the whole system).
I've already talked about transactions and unordered key stores in other posts.