>>
6) What precisely are the semantics of the hash-table returned from
okvs-transaction-metadata? Does this documentation need to refer to a
particular RnRs or other SRFI?
> Yes, it is a mistake. The hashtable is a R7RS hashtable. Thanks.
>> What happens if I mutate it? :)
> FWIW, it is at the start empty and is intended to be mutated. I
use in fstore to keep track of whether the transaction is "dirty" or
not. In this context, a transaction is dirty if it has mutated the
store.
It's not clear to me how it is intended to be mutated by the user.
okvs-transaction-metadata is a mutable hash-table. During the transaction, the user can hash-table-set! hash-table-ref stuff in it. Is it more clear?
It's not clear to me how mutating it impacts other parts of the SRFI.
Indeed, it doesn't impact other parts of the SRFI-167, but it allows to implement
abstractions on top of okvs while keeping things generic.
Also, I should add that hiding the okvs interface is an anti-pattern.
So doing things like wrapping okvs-in-transaction in another procedure
and exposing that as new-okvs-in-transaction is not good.
What I have experimented with is that when one provides its own transaction
procedures, it will forbid the extensions of the okvs. Therefore "layer" is not a
good name for database abstractions that rely on okvs. They are more
like extensions or composition of extensions.
When I started SRFI-168, it was wrapping the okvs-transaction-begin.
This was a mistake. Because if SRFI-168 start the transaction in say
nstore-in-transaction, another abstraction, can not know the transaction
was started or not. Instead, the new behaviour is that, it is always the
responsibility of okvs to start and finish the transaction. And abstraction,
take a transaction as an argument.
To some extent, this goes against the principle of:
"good abstractions don't leak"
okvs abstraction must leak to allow to implement other abstractions
that cooperate to build something bigger.
One way to workaround that bizarre thing, and instead every abstraction
works independently and doesn't have to be aware of what happens around it,
is to have some kind recursive transaction. That is start a transaction inside
another transaction, then each abstraction would have its class of transaction
that is created from a okvs handle or another instance of transaction.
Instead of "this is a transaction of transaction of transaction of okvs database".
With okvs-transaction-state we have a composition of different states...