work in progress

Introduction

Like for relational databases, there is a certain impedance mismatch between the content repository and objects which has to be solved.

Furthermore there are several problems which can be solved in more than one way. It is a design decision which of the possibilities are implemented.

General Rules

Data First

The "Data First" approach is taken. Our interpretation is that in a mapping of an object graph to a content repository should be as simple as possible. There are of course constraints which have to be taken into account, the main one beeing the (obvious) ability to retrieve objects. This again means that there has to be a way to uniquely identify objects.

Uniqueness on the path

the path is currently

contentRoot/className/identifyingAttribute

Content roots

Well, there is a configurable content root contentRoot for each application, or rather for each instance of JcrPersister. That is all about it atm..

Class and Package Names

The className is fully qualified, i.e. java.lang.String is used. Of course it might be possible to use package names ( java/lang/String i.e. depth of 3 insteand of one), but I do not see huge advantages atm.

Further strategies might be to have this part supplied from either annotations or completely from outside. Again, no big hurry atm.

Object IDs

The respective instances are identified by a attribute. The application is responsible for uniqueness. If a class is defined as

class Beer {
def sort 
def type
}

and sort is declared as identifying attribute, this would lead to

def ueli = new Beer {sort:"Ueli", type:"Independent Brewery" }
ueli.save()

would lead to

/beerRoot/ueli:
            type:"Independent Brewery"

This simple behavior will be enriched with other strategies:

• automatic key generation, very similar to RDBMS
• possibility to use multivalued keys
• explicitly define a key

Object Relations

Object relations are object relations, no more, no less. This means that I do not care about "has and belongs to many" when persisting data. These are constraints, and will be handled by node type management. This is my humble interpretation of the "Data first" approach. Future might prove me wrong, however.

Having said that, there is another design consideration worth being mentioned: Currently, there are 2 types of objects: those beeing persisted (I call them "instrumented") as objects in their own right. And the rest :). This, together with above approach means that there are all relations are handled between 2 instrumented objects are symmetric. There is no parent-child, no first-come-first or other such things.

There is some reasoning behind this, some of which has been discussed on my blog: An object beeing a child in a parent-child might become the parent in another parent-child relationship. Therefore it doesn't make sense to create a content hierarchy based on relations.

So what about xstream

All dependend objects which are not instrumented and are not easily mapped on JCR properties are serialized by xstream and stored as string nodes. Lazy, soooo lazy :).

Constraint handling

Constraints (e.g. mandatory values, relation types) are handled by node type managment. Currently this whole issue seems to be evolving in both jackrabbit and the JCR-283 specification process. This is of course a major task, which I gladly leave to the big guns to be implemented :).

Perhaps some workaround will be done to make it usable with grails, dunno yet.

Other Goals

There are other goals to be achived:

1. Take it easy: The whole Object-Content-mapping should be fault tolerant: If there are more attributes in the content repository than in the objects: so what?
2. Understand it: the persisted values should be easy to understand & reuse. The usage of xstream is of course a contradiction to this, I know