From: Amirouche Boubekki <xxxxxx@gmail.com>
Date: Saturday, June 29, 2019 4:13 PM
[...]
More questions below:
[...]
Many of these points are less strong when SRFI-167 is only used to provide the raw OKVS storage for SRFI-168, but SRFI-167 is high quality and I believe ought to support other uses, including ones where the schema had been defined by another, probably non-Scheme application.
How does it relates to transactions?
Old schema, like ones that started with the original UNIX dbm mentioned below, likely don't take advantage of transactions which weren't available back then. But I could see users of these applications upgrading to KVSes opened in auto-transaction mode, although they wouldn't necessarily be OKVSes.
Ok
This boils down to how much SRFI-167 wants to be a general OKVS interface, vs. one for new Scheme applications. I suppose if it wanted to be very general, it would also support non-ordered KVSes.
I did not plan to support dbm hash database. Nor do I planned to support things like cassandra or hbase but that is another topic I guess.
If we can provide a smooth upgrade path for dbm then I agree that it would be a good thing.
Do you mean someone replacing a dbm database used by a non-Scheme application with a OKVS, which should be pretty simple, and then also wanting to (also) manipulate the database with Scheme?
[...]
- I cannot see any way in which this requested change does not make SRF-167 more complicated, and probably more ugly
Maybe it is not ugly to add 'no-transaction. I am not sure as of right now.
Right now the database handle for the specific OKVS being manipulated is subsumed into the transaction handle. My idea of an "in-your-face", remind you of the danger of using the no-op 'no-transaction handle cannot "cleanly" supply the database handle. I suppose you could require setting the value of no-transaction to the database handle, and the code below eval-ing no-transaction, but that's tortuous, and "ugly".
My best idea is to disentangle the database and transaction handles, which will make the API more complicated or at least more ceremonial, but perhaps not "ugly".
Ok, I agree with the idea of offering an upgrade path for dbm-like based applications.
Question: Should it be explicit in the specification that the library offers such a upgrade path?
Is anything needed, or would an example suffice?
This is in the context of adding a no transaction option to SRFI-167, and many old application databases not caring, since they were written before dbm databases added transaction.
Also I agree that having a way to not specify transactions because it would allow
for a fast path for insertion on some implementation.
If the specification does not rely on 'no-transaction symbol or #false, I suppose
the following is the beginning of a proposal:
For the 'no-transaction change, while I
don't like it, other than requiring both a database and transaction
handle, the only idea I've come up with is to have okvs return a
procedure. When called, it returns the equivalent of the current
transaction handle, so from the tutorial:
(define db (okvs '((home . "/tmp/wt") (create? . #t))))
(okvs-in-transaction db (lambda (txn) (okvs-set! txn (pack "hello") (pack "world"))))
becomes:
(okvs-in-transaction (db 'no-transaction) (lambda (txn) (okvs-set! txn (pack "hello") (pack "world"))))
or with less ceremony, but not clean to add a second operation and put both in a single transaction:
(okvs-set! (db 'no-transaction) (pack "hello") (pack "world"))))
Not elegant, especially whatever is the opposite of (db 'no-transaction), but maybe it'll help spark a better idea.
I prefer the second solution as it is more straightforward with a slight change
where I avoid that db returns a procedures:
(okvs-set! db (pack "hello") (pack "world"))
It seems to me there is no existing library in r7rs that return a procedure.
I don't know if it intentional or the case did not present itself.
The above is something like the current "SOME" argument ... ah, if you want to keep that instead of indicating the alternatives in the argument list, "SOMETHING" is less grating to my ears.
Regarding okvs-range and okvs-prefix-range, I propose that when an okvs record
ie. db is passed as argument those procedures return a list of key-value pairs.
You've dropped that idea, but it prompts me to suggest avoiding having to know the maximum prefix or even beginning prefix, some set of arguments that explicitly generate the whole set of key value pairs. 'maximum-key might do, perhaps 'minimum-key as well. Not over-specifying, getting specific as your commit comment did, could allow a database to more efficiently return the whole set.
Since dbm, would need to do a full "table scan" anyway to emulate those procedure
it does no harm. Also, since there is no transactions, the generator does not make sense,
because it would require to do generator->list then list->generator to be able to produce
the generator.
We could assume an automatic transaction for each key value pair generated. We also have to consider the case where old non-Scheme code is using the database at the same time new Scheme code using transactions does. Otherwise is there any point in using SRFI-167 for this conversion use case?
The change will allow much better user experience at the REPL.
That's something I'm going to be emphasizing in my reply to John on mutation triggers vs. constraints, safety when using the REPL to manipulate the database, for e.g. maintenance purposes.
- Harold