okvs-close does close the database, I don't understand. What other name could take okvs-close?
5) What happens if the user does not call okvs-close? What must we assume should happen even if it doesn't in practice? Total data corruption?
It depends but from my experience it is not total data corruption. This is implementation dependant. What happens in wiredtiger, is that if you do not close
the database and the wal? is #f then the data is not written completly to the disk. In FoundationDB, I did not notice such behavior.
6) What precisely are the semantics of the hash-table returned from okvs-transaction-metadata? Does this documentation need to refer to a particular RnRs or other SRFI?
Yes, it is a mistake. The hashtable is a R7RS hashtable. Thanks.
What happens if I mutate it? :)
FWIW, it is at the start empty and is intended to be mutated.
I use in
fstore to keep track of whether the transaction is "dirty"
or not. In this context, a transaction is dirty if it has mutated the
store.
7) If okvs-transaction-metadata returns a hash-table why call it metadata?
I understand metadata is misleading. I considered the names "context" or "environment"
but those are misleading too. I might just change to what you say, okvs-transaction-hash-table.
8) Could okvs-debug simply be made a degenerate case of okvs-range?
We briefly discussed that. The idea behind okvs-debug, is that you can use
it anywhere without transaction ceremony, that is a debug procedure.
It could be seens as (okvs-range-for-each db start end proc) or something like that.
I use it like that:
(okvs-debug db pk)
Or most likely something like:
(okvs-debug db (lambda (key value) (pk (unpack key) (unpack value)))
where key and value are packed.
And pk is defined as something like:
(defie (pk . args) (write args) (car (reverse args))))
What is sure is that you can implement it in terms of okvs-range.
But you need to know the END of the range. See okvs-maximum-key
which is not defined in embedded ordered key-value stores like
wiredtiger and leveldb.
I am not in favour of removing okvs-debug.
9) What does it mean for the 'home' in (okvs home) to be an address?
It is implementation dependant. I guess, It is most likely a string.
10) What is an example of a useful 'config' going into okvs-close?
That is an easy question, I kept that in the specification to allow to blend
better with wiredtiger. Here is the configuration spec of connection-close:
11) What is an example of a useful 'config' going into okvs-transaction-roll-back?
Similarly, this is done so that it is possible to bind wiredtiger, but right now wiredtiger
doesn't use it, see:
But it does use config on commit:
12) Given continuations and the like (super noob here w/ Scheme) why does one need explicit transaction begin/commit/rollback at all? It seems like okvs-in-transaction would cover all use cases. Especially given the everything-must-be-committed-or-rolled-back warning at okvs-transaction-begin.
Good question. That is a copycat, basically FDB bindings provide those procedures even if they also have an equivalent of okvs-in-transaction.
13) Is start-key/start-include/end-key/end-include some best practice from elsewhere? How far can you go in simplifying the API with a half-open interval [start, end) where end is implied to be okvs-maximum-key when omitted?
okvs-maximum-key is staged for removal, it seems you prefer to keep it.
Like (briefly) discussed in
this thread, there seem to be no good reason
to do an half-open interval.
If what you want is to retrieve all values of a given "space" the space
must be anyway prefixed with a particular "value" to be able to tell which
keys are from the space you are interested in.
This is missing from the okvs specification, but hinted by the presence
of okvs-prefix. To emulate tables (or collections) in okvs, one must prefix
keys with a particular value (that does not share a prefix with another space).
So that, we you want to retrieve all values from that space you can query
by prefix.
What If you really want to do a half-open interval query [start, end).
Given the previous tentative explanation, space / subspaces of keys
always have a common prefix. Then half-open query is equivalent to
(okvs-range txn start-key #t (strinc start-key) #f)
where strinc is defined in the sample implementation (and used in okvs-prefix)
as the procedure that returns the first bytevector that is not prefix of start-key.
That achives half-open query in real world scenario.
This leads me to think, that we might make strinc part of the specification.
Useful references:
There is similar code written in Java in the same repository.
14) Is okvs-debug a very small amount of logic atop okvs-prefix where the prefix is trivial?
I don't think it does. You can not query FDB using the empty prefix. See the definition of strinc.
15) Why don't all the procedures returning an SRFI-158 generator have some common token in the name? Some are called 'range' while okvs-prefix omits it.
I am not sure I understand the question correctly.
In SRFI-167, there is only okvs-range and okvs-prefix that return generators of key-value pairs.
In SRFI-168, nstore-from and nstore-where return a generator of bindings.
nstore-from does a prefix lookup but since the actual subspace prefix is not
known by the application. So we can not rename nstore-from to nstore-prefix
or nstore-range-prefix.
16) Absent should/must/etc language around transactions, what happens during commit/rollback is underspecified.
I will try to improve the situation.
17) What happens to an uncommitted/rollbacked transaction when okvs-close is called?
The usual escape hatch, it depends of the implementation. This makes me think that we might
be better served with something like (call-with-okvs home config proc) that does close the database
at the end.
18) Why might okvs-range and the like take an offset parameter in config? They could simply use start-key = "last seen" and set start-include of #f.
Good remark. It is an easy path but slow way to implement pagination. The proper way to paginate is what you explain.
Maybe it doesn't have its place in the specification.
19) Thanks for reading this far.
Thanks a lot for the feedback, I hope I answered all the questions correctly.