jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu ☀" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Content Object Mapping - jcrom.org
Date Tue, 05 Feb 2008 17:21:14 GMT
I am trying to summarize my comments below...

(to Alex Lukin):

> 1) Current ocm in jackrabbit source tree does not have anything in common with JPA annotation
and/or ideology

Because it started on that direction. That doesn't mean it is the best
approach. But falling back again to the Hibernate parallel: once JPA
was introduced they were able to add support for JPA quite soon,
considering they have had a stable ORM. I assume the same will happen
here sooner or later.

> 2) JPA is based on relational approach and does not work properly with tree-like structures
we use often with JCR

That's partly correct. Indeed the theory of relational storage and
tree-based storage are radically different.

> 3) JPA is monstrous as current jackrabbit OCM is.

I take this as your opinion, so I will not really comment on it.

> I checked jcrom and created nodes in 5 minutes. Current OCM took much much more time
to go trough broken docs, complicated tests and hanging ends... [...]
> >
> > So my opinion is: Simple and quick OCM like jcrom.org is just great solution.
> >
> > If some standard-addicted company wants to implement JPA on top JCR - that's good.
> > If current "official" OCM is more flexible and powerfull - that's good too, but
I need working OCM now and can't wait new implementations and neverending doc fixings.
>

You are mentioning the current status of 2 projects and your own
needs. That's fine with me, and as I said: I do appreciate any efforts
in making JCR adoption easier. However, my comments were more about
the future of this technology and things that people looking into
creating projects around JCR should be looking for.

(to Ivan Latysh)
> Just my 2 cents, Jack Rabbit will not provide any advantages for Java Object
> Mapping, on the opposite side, will cause you many problems. As it mentioned
> before JR works with tree structures and not collections.
>

I must confess that I don't get your comment. I don't think OCM or
JCROM intention is to innovate in terms of Java Object to X mapping
but rather to address the problem at hand. And they are not looking to
provide a generic solution, but rather a working one in this field.

(to Christophe)

> There are commons points between both solutions in term of annotations but
> JCROM doesn't support lazy loading, interface and Ă­nheritance, custom
> converter, .... Futhermore Jackrabbit OCM makes more abstraction on the JCR
> API which is not the case of JCROM.

These are indeed feature that everybody will start considering at the
point their application gets complex enough. However, people may
consider that annotation based metadata to be easier to create and
maintain than XML, and so putting them together will make sense. I am
not saying that in the current form, or in a more JPA-like form.

(to David)

>> Moreover, when speaking about mapping solutions I would be interesting
>> in the level of customization they allow
>> and keeping in mind some of the JCR storage restrictions how these are
>> handled (the first example that comes into my mind is a parent-child
>> relationship with 10k children).

> I am not sure if you are referring to the performance penalties in the
> current jackrabbit implementation with a large number of direct child
> nodes. I want to be clear though that JCR does not have any limitation
> or performance penalty with a large number of direct child nodes.

You are right: I was referring to the current Jackrabbit limitation.
Even if JCR does not have
any such limitations (because it is a spec), by looking at the history
of the tree-based storage
I think we can say that this was almost always a real problem
(and if we take as example the FS implementations we will notice that
just the latest implementations
have been finally able to solve this old historical problem).

> I am convinced that the JCROM project would be happy to receive a patch
...after all it is an opensource project ;)

Well, my current status (plus my financial statement) are telling me
that I am not the right person for this.
Moreover, I do think that is time to leave some room for the younger
to get involved in the open source ;-).

cheers to everybody,

./alex
--
.w( the_mindstorm )p.
Mime
View raw message