Tracker based ORM

This Summer of Code proposal is about building an ORM using Tracker as a backend. Tracker (for versions 0.7 and above) is an RDF database, with which you can interact using the SPARQL query language. Dealing directly with SPARQL can sometimes be tedious, this project aims at building a higher level layer above RDF, where the developer can deal with native objects and get them reflected in Tracker's database.

The ORM will read a list of mapping files, and produce source code for a target language (currently Vala, but the design will be modular enough to allow plugging other output languages). The generated classes will be proxies to RDF classes in Tracker.

See also

• Tracker

• Cayenne, a Java ORM for relational database working the same way as this ORM (generating overridable proxies)

• My blog, where I'll post reports about my progress (specifically, look at the Hormiga tag)

• Intoductory blog post about the ORM

• Some design notes about the ORM

Proposed name

I'm going to name that ORM "hormiga". It means "ant" in Spanish. An ant is lightweight, and works hard. I'd like to have both those qualities for the ORM

Give me the code!

All the code and documentation is hosted on my git forge.

Documentation

This is a preliminary documentation. There are no API/ABI stability guarantee yet, nor there is a guarantee that this documentation is up to date (you've been warned :-p )

Components

Hormiga is composed of several parts:

• the hormiga binary, used to generate the proxies

• the libhormiga library, used at runtime by the programs using Hormiga. It contains various bits of code used by all proxies generated by Hormiga, therefore having it as a shared lib reduces the overall memory usage.

When shipping code that uses Hormiga, you can ship the generated proxies so that users who want to compile the code don't need to install Hormiga. However, the libhormiga lib will always be needed at runtime.

Workflow

Various steps are required when using Hormiga:

1. Write the mapping files

2. Run hormiga on those mapping files to generate the proxies

3. Use the proxies in your application

Those various steps are explained below

Writing mapping files

Mapping files are used to tell Hormiga what classes you want to generate proxies for, and what predicates you want to use. There is one mapping class per file you want to map, and you can pass several mapping files to hormiga at the same time.

Mapping files must have the extension .map. They are JSON files. The example below shows the various fields that can exist in a mapping file:

{
        "Class": "nmm:Photo", ①
        "Name": "Photo", ②

        "Properties": [ ③
                {
                        "Property": "dc:title", ④
                        "Name": "title", ⑤
                        "GenerateLoader": true ⑦
                },
                {
                        "Property": "nao:hasTag",
                        "Range": "nao:Tag", ⑥
                        "Name": "tags"
                }
        ]
}

Generating the proxies

When all your mapping files are written, run hormiga on these to generate proxies. Currently, the only supported target language is Vala.

If using the mappinf file above, you would also need a mapping file for the nao:Tag class. In that case, you would run

hormiga -O /path/to/dir/with/ontologies Photo.map Tag.map

The ontology directory is generally the one used by Tracker, which is ${prefix}/share/tracker/ontologies. The command above would generate two files, Photo.vala and Tag.vala.

Using the proxies

How to use the proxies differ depending on the target language. The complete source of the example above is available at http://git.mymadcat.com/index.php/p/hormiga/source/tree/master/examples/hormiga . It is probably the best way to have a clear understanding of how to work using Hormiga.

Bugs, suggestions etc.

There is an issue tracker on the forge, which you can use. I also generally hang on IRC, on #vala and #tracker as abustany. Any feedback will be appreciated!