Re: [MirageOS-devel] [Irmin] Listing keys at a path

[Thomas Leonard <talex5@xxxxxxxxx>]

On 13 June 2016 at 17:13, Sean Grove <sean@xxxxxxxx> wrote:
> I've tried to follow the tutorial, look at example Irmin usage, and
> experiment trial-and-error style, but haven't figured this out.
>
> How can I retrieve a list of keys at a given path?

(** Hierarchical read-write stores. *)
module type HRW = sig
  ...
  val list: t -> key -> key list Lwt.t
  (** [list t k] list the sub-paths of the path [k] in [t]. *)

is included by BC and VIEW, so you can list any branch (store) with that.

> If I've created a Store/View/Config via e.g.:
>
> ```
> module Store =
>   Irmin_mem.Make (Irmin.Contents.String)(Irmin.Ref.String)(Irmin.Hash.SHA1)
>
> module View =
>   Irmin.View (Store)
>
> let config =
>   Irmin_mem.config ()
>
> let empty =
>   Store.Repo.create config
> ```
>
> What is the relationship between View.db (which is the type required by e.g.
> View.of_path) and empty (which is a Store.Repo.t, ignoring Lwt)?

empty is a View.t (an empty view).
A View.db is a branch (store) from which a view can be created.

> I can't
> figure out how to get a View.db given a Store.Repo.t, except perhaps by
> creating a transaction. But transaction actions are only `Merge | `Rebase |
> `Update, none of which I want to do.

module View (S: S): VIEW with type db = S.t
  and type key = S.Key.t
  and type value = S.Val.t
  and type commit_id = S.commit_id

So any BC store (branch) S.t is also a View.db.

> The example here
> https://github.com/mirage/irmin/wiki/Irmin-API#listing-sub-paths reference
> `v`, which is only defined inside of the transaction above, so perhaps
> reading from Irmin in this way requires a transaction? But transactions must
> return unit (again, ignore the wrapper types), and so if I want to list
> keys, should I allocate a ref outside of the transaction and then bash on it
> in place? But the transaction may be replayed if there was a conflict, so
> I'll need to first reset the ref?
>
> The example in the API docs
> (https://mirage.github.io/irmin/Irmin.html#examples) is (presumably?) more
> up to date, but doesn't include this (ever so slightly) more advanced usage.
>
> Thanks for any help!

I do find the Irmin API quite confusing. I've been working on some
alternatives in DataKit, which perhaps could be folded back into Irmin
one day:

1. https://github.com/docker/datakit/blob/master/src/ivfs/ivfs_tree.mli

provides a simpler alternative to a View, without the mutable state
and transactions stuff. It also exposes the tree structure directly.
In this API:

- You ask a branch for its head (a tree) and then read from that. You
can't read from a branch directly (which is racey anyway).
- Trees are immutable, but you can create new ones from existing ones.
A https://github.com/docker/datakit/blob/master/src/ivfs/ivfs_rw.mli
is a ref cell pointing at a tree if you prefer a mutable API.

2. https://github.com/docker/datakit/blob/master/src/client/datakit_S.mli

doesn't wrap Irmin directly (rather, it wraps DataKit's 9p interface
to it), but it could form the basis of a new Irmin API.


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