Thanks for the clarification / summary.
I have been slow to apply the requested changes partly because
I am not sure and because it is different from what I was expecting.
(Oops, forgot to CC this to the list.)
Summarizing the major points in the discussion that started 5 days ago:
- SRFI-167 forces all operations use transactions, rather than (strongly) suggests
- That requirement adds ceremony for isolated single operations when a database automatically executes them in a transaction, like (okvs-in-transaction db (lambda (txn) (okvs-ref txn (pack "hello"))))
- Some OKVSes don't support transactions; requiring transaction boilerplate creates a false sense of security
- For databases with a single operation automatic transaction feature, this requirement turns a single round trip into 3, start transaction, operation, commit transaction, which may be significantly more expensive
I disagree with that. In the case of LevelDB, transaction-begin et al. are nop procedures. I agree that it gives a false sense of security.
- There are applications with very high required rates of write operations; adding round trips is bad, and for some applications a trade off of losing a portion of the incoming operations is perfectly acceptable
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?
Per Wikipedia, the original UNIX dbm library was released by AT&T in 1979 (no doubt part of the Research UNIX Version 7 release that same year).
AFAIK the original dbm library doesn't support transaction and is hash database.
Counter arguments include:
- SRFI-167 doesn't have to be a general purpose OKVS store
- Requiring transactions is not necessarily a bad thing
- As application developers "climb the ladder of features", starting with transactions from the very beginning makes mistakes less likely and development cleaner
I agree with the above points.
- Bolting a transaction facility onto a non-transaction supporting OKVS is not tremendously difficult
I am not convinced the implementation of transactions is that easy.
- 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.
- Harold
----- Original message -----
Date: Saturday, June 29, 2019 5:57 AM
There is several concerns raised about to support transaction-less "mode" in this srfi.
I don't understand why it is a good thing.