incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: How can aggregation be mapped in OCM?
Date Wed, 06 Sep 2006 08:00:57 GMT
Sorry for the delay, I will come back on this mail tommorow. Some
urgent stuffs to do.


Thanks,
Christophe

On 9/5/06, Dan Connelly <dsconnelly@adelphia.net> wrote:
> Christophe
>
> 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">
>     <supertypes>
>       <supertype>mix:referenceable</supertype>
>       <supertype>nt:unstructured</supertype>
>     </supertypes>
>   </nodeType>
>
> 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 = matches.next();  // take the first one
>           String uuid = theNode.getUUID();   // assume graffito:object
> node type
>           Node refNode = parent.addNode(fieldName,"graffito:object");
>           refNode.setProperty(PersistenceConstant.MUST_DEREFERENCE,
> 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 <dsconnelly@adelphia.net> 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
> >
>
>


-- 
Best regards,

Christophe

Mime
View raw message