jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: OCM:To Path or Not to Path
Date Sun, 05 Oct 2008 08:11:02 GMT
On Fri, Oct 3, 2008 at 08:18, Boni Gopalan (BioImagene) <
Boni.G@bioimagene.com> wrote:

> While implementing an Abstract DAO layer on top of OCM as part of a data
> management system we are building; I came across one issue.  While the
> mapping of a Bean to a JcrNode could be specified either through
> annotations or through xml mapping; the location in the tree at which
> the mapped node should be added need to be specified as an attribute in
> a bean (the path attribute).  I do not feel it is robust.  Consider the
> case of somebody moving a Hibernate based Dao layer to JCR through OCM.
> Suddenly they are hit with the issue of an extra attribute to be added
> to the data transfer objects.  Such constraints could make adoption
> difficult.

Yes, i understand the problem but I think it is not possible to translate
directly a ORM mapping into a OCM mapping.
Another problem : the primary key (eg. a sequence number)  in the ORM world
is not mandatory in the OCM world which is more or less the UUID.

Concerning the path problem, see a previous discussion on  [1]. please
review this discussion and let me know what you think about that.

> How I resolved the issue was through a two fold approach.
> 1.      specify an envelope bean of the following structure to hold the
> actual data.
> Envelope{
>      Object data;
>      String path;
> }
It should work with the current code base.

> 2.      Define a naming strategy bean for the system that encapsulates
> the path resolution logic.
> So, when ever I have to save a new root level node, I resolve the path
> (analogous to deciding the table in OR Mapping) through the naming
> strategy and then use the envelope bean to persist the data.  The flip
> side is that All my root level sppl specific nodes are of the
> ocm_type:Envelope :-(.  It works fine; but would be nice to have this
> flexibility built into the OCM layer itself.   What I mean  is to have a
> notion of root level bean mappings and the resolution of the node names.
I'm not sure that this kind of strategy can be built into the OCM layer
because there are many use cases where it is not possible to use it. It is
too specific for a framework.

My conclusion is if you see the OCM pojo classes similar to the JPA
entities, the path becomes insteresting because the UUID is not mandatory.
Otherwise, we have to specify the path into the OCM API see [1] ... but the
discussion is always open :-)


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message