Questions About the Design

[rizo]

Is there any documentation about the current or planned design of Irminsule?

I understand that it follows the same principles as Git and can use it as actual storage backend, but that's a very general description.

How the data will be structured and related? Will there be a possibility to make queries?
Can the database store large binary blobs?

Thank you in advance for the answers!

[samoht]

Seems that I missed that issue, sorry. There are no proper documentation for Irmin yet, but I plan to write a one in the next weeks (before the mirage 2.0 release).

The data is organised as a prefix tree (ie, a filesystem-like), with the natural corresponding queries (ie. get all the subdirs of a given path). More complex queries will depend on the underlying data-structures. For instance, you can encode persistent queues and efficiently query the head of queue, see https://github.com/samoht/merge-queues

Which kind of queries are you interested in ?

[rizo]

Hi, no problem! Thanks for the reply! Its good to know the next mirage release is so close!

After exploring the code and the examples I am gradually starting to understand the core principles of the database. The way it uses Git on the storage level and the way views provide partial representation of the database paths.

I started experimenting with Irminsule to build a storage backend for a knowledge graph. My idea is to represent the user data as a graph with items and relations between them. In the same fashion it's done in graph-based and ontology-based databases.

As you said, the queries that are not hierarchical by nature need to be adapted to the underlying data structure.

How would you advise to model the graph data structure on top of Irminsule? Do you think a custom view could be the good way to go?

[rizo]

Closing. The latest post on the mirage blog provides a good description of the architecture. After reading it I understand that my last question is out of the scope of the project.

[avsm]

It's not entirely out of scope -- you could build the knowledge graph representation on top of the basic DAG structure that Irmin exposes. One advantage (for example) might be that index branches could be updated in lock step with insertions, so that a client can pull a search index of the graph that's consistent with the graph itself.