 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
19 messages in org.apache.jackrabbit.devRe: Content Object Mapping - jcrom.org| From | Sent On | Attachments |
|---|---|---|
| David Nuescheler | Feb 5, 2008 3:47 am | |
| Alexandru Popescu ☀ | Feb 5, 2008 4:11 am | |
| Jukka Zitting | Feb 5, 2008 4:16 am | |
| Christophe Lombart | Feb 5, 2008 4:43 am | |
| Alex Lukin | Feb 5, 2008 4:47 am | |
| David Nuescheler | Feb 5, 2008 4:53 am | |
| IvanLatysh | Feb 5, 2008 6:40 am | |
| Alexandru Popescu ☀ | Feb 5, 2008 9:20 am | |
| Alexandru Popescu ☀ | Feb 5, 2008 9:23 am | |
| Alex Lukin | Feb 5, 2008 10:25 am | |
| Christophe Lombart | Feb 5, 2008 10:53 am | |
| Jukka Zitting | Feb 5, 2008 11:37 am | |
| Padraic Hannon | Feb 5, 2008 11:59 am | |
| Alex Lukin | Feb 5, 2008 12:05 pm | |
| Christophe Lombart | Feb 5, 2008 12:49 pm | |
| Alex Lukin | Feb 5, 2008 1:01 pm | |
| Alexander Klimetschek | Feb 6, 2008 10:54 am | |
| ogg | May 16, 2008 4:06 am | |
| Jukka Zitting | May 16, 2008 5:09 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Content Object Mapping - jcrom.org | Actions... |
|---|---|---|
| From: | Alexandru Popescu ☀ (the....@gmail.com) | |
| Date: | Feb 5, 2008 9:20:51 am | |
| List: | org.apache.jackrabbit.dev | |
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.