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.
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).
It is a debug procedure. It is not meant to be used to actually manipulate the database.
Not all access to a database is "normal"; some is maintenance. For example, dumping the entire database by unpacking the keys and values to hex strings instead of some internal representation. Another example: iterating through the whole database to look for invalid keys according to some predicate. As things stand, a buggy program with write access could write information outside the standard prefixes of a given use case. No one will see them but they will bloat the database forever. If the program is malicious, it can use such invalid keys as a covert channel to anyone with read access.
But for these things okvs-prefix with the null prefix is sufficient. So I suggest dropping okvs-debug, which is exactly equivalent, altogether.
It used to extend to transaction behaviour somehow, it is used in
fstore.
It is workaround the fact one can not use okvs-in-transaction with custom semantics.
Another way around that would be to override/extend okvs-in-transaction (or okvs-transaction-begin et al.)
from user code but that is not possible in R7RS.
It's possible by importing the library and renaming okvs-in-transaction and then providing your own.
I think however that instead of requiring a hash table, you should have a procedure that creates
the correct kind of opaque object that the implementation wants. (I'm still not sure I understand
it completely.)
(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 ...".
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgI could dance with you till the cows come home. On second thought,
I'd rather dance with the cows when you come home.
--Rufus T. Firefly