Re: [MirageOS-devel] Irmin API newbie questions

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

>>> - Irmin makes it easy to read data directly from a branch (tag), but
>>> this is usually unsafe, since a tag can update while you're reading
>>> it. Therefore, I think I always have to first get the head commit,
>>> then create a new store for that revision, then read from that. It
>>> might be safer if a branch just provided a way to get a commit, and
>>> reads had to be done from a fixed commit.
>> 
>> Hum, reading a tag should not be unsafe as the RW backend should ensure that 
>> updates are atomic. See Get_unix.with_write_file[2] for example where we use 
>> the fact that "rename" is the only operation guaranteed to be atomic on 
>> POSIX filesystem.
> 
> That's OK if you're only reading a single key, but usually you'll want
> a consistent set of values, all from the same commit. e.g. if I do
> 
>  I.read t "key1" >>= fun value1 ->
>  I.read t "key2" >>= fun value2 ->
> 
> then value1 and value2 will usually but not always be from the same
> commit, which is an easy mistake to make. This would be safer:
> 
>  Branch.head_commit t >>= fun c ->
>  I.read c "key1" >>= fun value1 ->
>  I.read c "key2" >>= fun value2 ->

Ha I see, that you want is a transactional sequence of operations. In that case 
you might want to use views [1]. All the read/write done on that view are 
guaranteed to be isolated. I still need to ensure that merging back in the 
store is really atomic (same issue as with all the other high-level operations).

Thomas

[1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view



_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel