On 1/3/22 08:41, Thomas Gazagnaire wrote:
Hi Mindy :-)
The semantics intend to match the “commit” operation of Irmin, e.g. a commit
will ever read what is in the current checkout (and/or what have been written
in that commit since the beginning of the transaction). The important bits is
that it won’t be able to read writes done by concurrent writers.
Good news - this implementation trivially fulfills this requirement by
not supporting concurrent writes ;)
It’s obviously not super easy to implement if you do not have access to a
transactional file-system. In that case, I won’t worry too much about it; the
only important thing is durability, e.g. the data should be written (and
flushed) to disk once the operation has completed. We could probably edit that
docstring to remove the sentence about “reading inside a batch”: I don’t think
any user of Mirage_kv is relying on this behaviour at the moment.
Thanks for the reply! I got a few suggestions for how I might implement
this, but to be honest they don't seem worth the increased complexity to
me. I think any users who want to use this functionality should
definitely be using `irmin` on top of the storage solution of their
choice, rather than my Mirage_kv.RW implementation.
If the docstring is changed as you describe, I'll implement `batch` by
just executing the given function; if not, I'll have all batch
operations error out immediately, so nobody gets the wrong idea.
Thanks!
-Mindy
