Date: Saturday, June 29, 2019 9:46 AM
That is very difficult to do validation at this level. OKVS manipulates bytevectors, to validate keys and values it would require to unpack the bytevector which is not know at this level. I acknowledged that validation is missing piece in the whole framework (SRFI-167 + SRFI-168), I am thinking about ways to improve the situation, but that will not be part of any current SRFI.
A simple approach would be to associate a simple Scheme function with each open database that is called before inserting any key-value pair. It is passed the key and value as its arguments, and returns #t if the combination is valid and #f if it is not. Of course the behavior of this function would depend on how the store was used. That would be straightforward to implement within the library.
That's the sort of simple thing I was thinking of, and I think it would be in the scope of either or both SRFIs.
If the constraint is to be persistent, it would need to be stored in the database under some well-known key, which would mess up the complete freedom of the user to use any key desired. If that were overcome, a fully general constraint would have to be stored as a lambda expression and eval'd in some minimal library (which would be worth defining anyway, probably).
That's a capital idea, although evaluating random external code invites mischief. Arguably more beyond the scope of these SRFIs, especially since it would be nice to store multiple constraints, but it would be extremely useful, and help bridge the validation capability gap between simple OKVSes and the better RDBMSes.
[...]
(okvs-transaction-commit transaction config) looks like it should be (okvs-transaction-commit transaction [config]).
Yes.
You should make clear if config is a single argument (containing what?) or just additional arguments, which I think is
better. If you do that, change "[CONFIG]" to "args ...".
In the Specification | Okvs and Transaction section at the beginning of the SRFI, I think it's well defined, modulo capitalization:
In the following, CONFIG is always an optional parameter that is an association list. Some configuration options are specified to ease portability. If an implementation doesn't recognize an option, it must be ignored. Default values are implementation-dependent. It is an error if this argument is not an association list.
- Harold