Re: [MirageOS-devel] Irmin API newbie questions

[Thomas Leonard <talex5@xxxxxxxxx>]

On 5 March 2015 at 14:15, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>> 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.

How do I find out what commit the view was based on? It looks like it
just reads whatever is current for the store, which could have changed
since I checked it.

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

That would be very useful!

Even pure functions are allowed to allocate data (which can later be
GC'd), so I don't see a problem with allocating objects in the store
in the same way.

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



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