incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Connelly <>
Subject Re: How can aggregation be mapped in OCM?
Date Tue, 05 Sep 2006 17:48:13 GMT

I don't have any fully developed use cases yet, but, yes, there are some 
pre-conditions that I do accept.   

In particular, I accept that every model object will have a jcrNodeType 
that has mix:referenceable as a supertype.

For instance:

  <nodeType name="graffito:object" isMixin="false">

This graffito:object type would be specified as the jcrNodeType of the 
model classes in the ocm mapping.   In addition to that usage, I would 
also have code for persisting references (pointers) using the same 
jcrNodeType.   So, where the parent node is already know, the reference 
node to a bean in that parent can be constructed as follows :

     QueryResult qr = query.execute();   // query criteria based on 
object identity, ie. id="true"
     NodeIterator matches = qr.getNodes();
     if ( matches.size() > 0 ) {
          Node theNode =;  // take the first one
          String uuid = theNode.getUUID();   // assume graffito:object 
node type
          Node refNode = parent.addNode(fieldName,"graffito:object");
uuid, PropertyType.REFERENCE);

An alternative to querying would be to could keep a HashMap associated 
with the JCR Session.   In this HashMap (global for the session), the 
object to persist is the key and its uuid string is the value.   If the 
lookup on the object returns null, then the object has not been inserted 
yet.  Insert it now and record its uuid in the hash map.

Any node in the Repository having a *property* whose name is 
PerstenceConstant.MUST_DEREFERENCE and whose value type is 
PropteryType.REFERENCE should not be used directly.   It should be 
de-referenced through the node with that uuid, regards of the path to 
that node.    De-referencing is node is done as node = 
session.getNodeByUUID(String uuid) and bean converter needs to handle 
all the exceptions that could be thrown by that call.

Pointer chains might exist for multi-step de-referencing.   Maintenance 
of such pointer chains can be a tricky because there is no real 
difference between pointers and data, which is the problem you find in 
the C language.    However, I think that issue is only a small concern 
for my use case(s) and I will defer it.

       -- Dan

Christophe Lombart wrote:

> On 9/5/06, Dan Connelly <> wrote:
>> Christophe:
>> Okay.   But it does get a little tricky, as follows:
>> ReferencingBeanConverterImpl#insert operation:   This must actually
>> create a node for the bean if there is no node for its already.   If the
>> bean has a node (elsewhere),  then a reference node is inserted
> If I remember correctly, a referencable node matches to a JCR property
> in the target node.
> Why to create subnode ? Sorry if  I'm wrong because I have not all the
> details on the JCR spec. I have to review it.
>> ContainedBeanConverterImpl#insert operation.   This must move the node
>> if it already exists elsewhere, leaving a reference node in its
>> place.    Otherwise, it creates and inserts the node for the bean.
> What do you mean by moving the node if it is already exist. How to
> check if it is the same node ? I don't understand all the details
> here. Can you give more information ?
>> Is this what you are suggesting?
>>        -- Dan
> Without some use cases, it is difficult to gives exact information but
> here are some thoughts on JCR references. This is just to start some
> discussions because I don't know if we have to implement the same
> features.
> Precondition to map a jcr referenceable node to a bean
> -------------------------------------------------------------------------------- 
> * The referenceable node already exists in the repo (of course based
> on mix:referencable).
> * If I remember correctly the JCR spec : the reference is stored in a
> property in the target node.
> Mapping file
> ------------------
> We have to check how to specifiy the references in the mapping file.
> We should support references from a bean descriptor but also from a
> collection descriptor. I mean it should be possible to create a
> collection containing some references to other nodes (objects).
> If we accept this situation, we have to find a way to
> 1/ [When retrieving the object containing the reference] : Map a JCR
> node property to a java bean and in the case of a collection of
> references, a series of JCR node properties into a Java collection (or
> map).
> 2/ [When updating, inserting the object containing the reference] :
> Map a bean attribute into a JCR property (UUID value) or a collection
> attribute into a serie of JCR properties.
> Let me know if I'm wrong because I don't remember all the details from 
> JCR spec.
> We have also to check how to avoid some performance issues (is it
> possible to use the existing features like proxy, auto-retrieve,
> auto-update, ...).
> Ohoh It is more than I expected 2 days ago :-(
> Christophe

View raw message