(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
- 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. 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).
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
- Bolting a transaction facility onto a non-transaction supporting OKVS is not tremendously difficult
- I cannot see any way in which this requested change does not make SRF-167 more complicated, and probably more ugly
- Harold
----- Original message -----
From: Amirouche Boubekki <xxxxxx@gmail.com>
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.