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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
