Re: [MirageOS-devel] Irmin API newbie questions

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> Should I make a view here instead? It looks like View.of_path does a
> load of copying. What I want is something that I can be sure will
> never change.

When you build a view, initially it just reads the head commit. Later, when you 
read elements from it, it lazily fetch and cache the sub-node needed, 
relatively to this commit. If you never write on the view, all the reads will 
be relative to the head commit at the time you created the view. Views are 
designed for this kind of short-lived, non-persistent and isolated sequence of 
computations.

> Neither views nor stores can ensure this I think (both
> can be written to). Possibly I should do the "I.of_head" inside
> R.make, but then I'd have to give it the repo (config) and task_maker
> objects too, which is also ugly.

would be very easy to add a RO view if you think that's useful.

> It seems strange, since the underlying Git model already provides
> immutable data structures (blobs, trees, commits), but Irmin seems to
> force me to treat everything as mutable.

well, if you want to persist things you need to mutate something anyway. 
Exposing an immutable API to Git would be a bit cheating as pure function would 
need to have side-effects to create new objects in the backends (when you add 
an element to a tree, you need to create the intermediate sub-node in the 
storage substrates). But others have already expressed some interest on having 
immutable views (see [1]), so I'll see what I can do.

Thomas
[1] https://github.com/mirage/irmin/issues/109


> 
>> I still need to ensure that merging back in the store is really atomic (same 
>> issue as with all the other high-level operations).
> 
> BTW, I read more of the storage spec and found:
> 
> "The use of the storage mutex to avoid race conditions is currently
> considered by certain implementors to be too high a performance
> burden, to the point where allowing data corruption is considered
> preferable."
> 
> So some locking will be needed anyway. It would be good to implement
> this only in the backend though, and have the rest of Irmin
> automatically be safe.
> 
>> Thomas
>> 
>> [1] http://mirage.github.io/irmin/Irmin.html#VALwith_hrw_view
> 
> 
> -- 
> Dr Thomas Leonard        http://0install.net/
> GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
> GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA


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