Le lun. 24 juin 2019 à 18:10, <xxxxxx@ancell-ent.com> a écrit :

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"))))

From the tutorial don't need this feature, and their code is thus more complicated with ceremony than required.

It could be made shorter and extensions in implementations are welcome.

I think we are both correct. My approach is to think than one should program

with transactional states in my some kind of modal development practice that

allows to prepare for future needs.

Also, the sample implementation that is in-memory has some transaction semantic.

When the transaction starts it picks the last version of the database and apply

modification to that version, when the transaction commit the database is replaced

with the updated / improved version. It really works in single thread setting.

Even with this simplistic design handling transaction state, it allows during development

to climb the ladder of features, by being mindful of transaction from the start, to

move to persistent storage or in-memory multithread settings (that must be dealt with at

somepoint). Even if two transactions from different threads (or green threads?) modify

different part of the version, when one ends the transaction makes its version of reality

the truth globalizing possibly ignoring / overring / erase modification made by other

transactions. There is no locking or versioning involved per key-value pair. It is difficult

to explain.

functional store does not versions key-value pairs (I am thinking about a way to do

that but I might take a shortcut that the extra space required for the fractal composition

of abstractions e.g. a space filling curve inside the a 4-tuple store is a waste of space

because the space filling curve is query along a single subspace.))

I am not sure what are the consequences of using call/cc inside transaction. Actually,

I just never use call/cc in transactions. My plan was to not rely on green threads

for my application. But now that I think about it, I might need it.

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. Is it a problem that the

REPL code run is too verbose?

The transaction handle might be replaced with #f, 'no-transaction or whatever, or made optional.

I would use 'no-transaction if I implemented that in the sample implementation.

Echoing Rhys Ulerich concern that "Databases not providing the guarantees one requests are scary...", the transaction handle feature in general could give a false sense of security if the underlying OKVS doesn't support transactions. This might be addressed by using the config facility or something like it, or SRFI-167 could suggest or require bolting on a transaction facility.

Yes, I plan to make some kind of validation of config. Does it require a framework?

- Harold