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.
Ok. And okvs-transactional will be gone in a future commit, I will replace it with okvs-in-transaction.
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.
Thanks for the feedback. I updated the spec.
3. "Read-committed" and "read-uncommitted" are spelled with two Ts (but consider the objections from FoundationDB).
I removed those from the specification based on the feedback in FDB forums.
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.
In the case of purely in-memory implementation like the sample implementation, HOME is useless. Nonetheless, I agree. I move HOME to its own argument and
CONFIG is still optional.
2. Likewise for 'read-only?' and 'create?'.
I am not sure about this one. read-only? is not necessarily supported by all databases. Making it mandatory will force the implementation to emulate it. So far, FDB doesn't support read-only?
create? is also subject to this. FDB doesn't have such a concept.
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).
About okvs-maximum-key, FDB and TiKV have that constraint because they don't allow to navigate the key space with cursor-next, cursor-prev and only have range queries.
Otherwise said, for embedded databases implementations will have to make up an arbitrary maximum key because there is none.
It seems to me, it is very unlikely that someone will scan the whole database for production purpose. The only usecase I can think of is for debugging, in that case
there is
okvs-debug. I think specifying the maximum key is not a good idea. Let me know what you think.