Re: [MirageOS-devel] Irmin API evolution

[Thomas Leonard <talex5@xxxxxxxxx>]

On 10 August 2015 at 15:05, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> On 10 August 2015 at 13:51, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>> Hi all,
>>
>> There are still parts in the Irmin API that I am not very happy about, so I 
>> send an email to get feedback from all the early users to check if they 
>> share my views.
[...]
>> 4. The Irmin API conflates the Git repository configuration and branch state 
>> into an Irmin store handler. For some operations (as listing all the 
>> branches in a repository) it doesn't make really sense. Maybe it's too 
>> confusing and you don't want that. See Cuekeeper'API[2] which exposes a 
>> different API, closer to what Git offers.
>
> No surprise that I agree with this ;-)
>
> Another reason to make an explicit Repository.t: Irmin currently makes
> some "global" state when you apply the functors. For example, I have
> to re-apply the Irmin.Basic functor to Irmin_mem.Make every time I
> want a fresh in-memory store. Having a Repository.t lets you do the
> set up operations for a repository once, not once per branch (too
> often) or once per functor application (surprising hidden state).

Another reason for an explicit Repository.t is that for
database-backed stores you only want to open one database connection
per repository.

Currently, when you do Store.create/of_tag/of_head, BC creates the
internal Contents, Node, Commit and Tag stores, each of which opens a
separate connection.

Is there any way with the current API I can share this? Currently, I'm
thinking of creating a hash table that maps database names to
connections and caching them there, but that's quite ugly.

It's a particular issue at the moment because I want Irmin-IndexedDB
to test for an old Irmin-format repository and upgrade it to
Git-format automatically, but there's no obvious place to do the test.
I guess I could have Contents notice the upgrade is needed and update
the Tags table at the same time, but that's messy too.

(also, a "Repository.close" function would be nice)


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
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