incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Connelly <dsconne...@adelphia.net>
Subject Re: How can aggregation be mapped in OCM?
Date Wed, 06 Sep 2006 13:28:28 GMT
Okay.   No rush here.

I am already moving ahead with the solution I proposed, but I am have 
run into an obstacle, as follows:

Just to update you:

I have a new class "ReferencingBeanConverterImpl" that extends 
AbstractBeanConverterImpl.

For my new class, the insert method has this *temporary* code:

        Reference ref = new Reference();
        try {
            ref.setUuid(parentNode.getUUID());
        } catch (UnsupportedRepositoryOperationException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (javax.jcr.RepositoryException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } 
        objectConverter.insert(session, parentNode, 
descriptor.getJcrName(), ref);
      

This replaces the bean by a Reference to the parent.    Next step is to 
have it to have Reference hold uuid of the object's node in the Repository.

So far so good, with one slight annoyance:   To make this work, I have 
described the Reference class in the mapping file.

Reference is an internal class that should be registered and handled 
automatically.  

Where is the hook that allows me to generate the descriptor for 
Reference class in the code.

       -- Dan



Christophe Lombart wrote:

> 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
>> >
>>
>>
>
>


Mime
View raw message