I spent a few hours yesterday in the company of Andi Vajda, lead developer of the data repository component of the Open Source Applications Foundation’s Chandler project. We talked about the technical details of the repository.
The Chandler repository is an object database with some interesting design features:
- All links between objects are bidirectional. Andi’s main motivation for this choice was to be able to guarantee to clients that references aren’t dangling without having to implement a garbage collector.
- All objects have universally unique identifiers (UUIDs) to make equality testing trivial.
- Repositories are versioned. Aside from the usual rollback capabilities this enables, client code can inspect a particular object as it was in any extant version.
- In addition to a conventional notion of class inheritance, the Chandler repository supports a notion of “cloud inheritence” for merging data schemas when copying objects from one database to another.
The repository layer is cleanly separated from the layer of Chandler that knows the semantics of calendar items, tasks, and so forth. That layer is responsible for mapping its items to repository items. Interchange of personal information is carried out at this higher layer, not by the repository. There’s an interesting bit of Python metaprogramming by Philip Eby that hides some of the mapping complexity from the application-level programmer.
I’m going to have a look at the source to see how this works. There are popular application-building tools that carry out object/relational mappings (moving between the objects that are convenient to use in code and the representations that are convenient in the usual relational database), but this is the first time I’ve come face-to-face with an object/object mapping tool. I’ll report back when I’m better informed.
[Thanks to Andi for fact-checking this post!]