From: Amirouche Boubekki <xxxxxx@gmail.com>
Date: Monday, June 24, 2019 12:17 PM
A quick reply on one point:
Date: Monday, June 24, 2019 11:57 AM
okvs and nstore operations require a transaction handle, but single stand alone database operations that are an implicit transaction, like:
(okvs-in-transaction db (lambda (txn) (okvs-ref txn (pack "hello"))))
[...]
This might also slow them down by requiring 3 round trip calls to the database when only 1 is required.
How 3 round trips? I don't understand the what is the problem if there is one....
I'm postulating KVS databases where you need one round trip to start the transaction and get its handle, one to do a single isolated operation, and one to commit the transaction. Vs. opening the connection in a default commit mode where operations are always committed unless a start transaction is first done for multiple following operations, followed by a commit (with possible nesting of transactions).
This by design, I want to recommend the use of transactions. Extensions welcome.
Currently the API forces people to use transactions, and your idea that people should use them from the very beginning of application development prior to "climbing the ladder of features" has a lot of merit.
I too favor a very strong recommendation to use them, but I don't want to leave performance on the table when safe. Which is why I suggested the 'no-transaction handle option you liked, that makes the concept of transactions very in-your-face, even if you're not using them.
Here's something I just thought of that I really do not like, but maybe it'll spark a better idea, adding okvs-in-fake-transaction....
- Harold