Re: Content Object Mapping - jcrom.org

[ogg <ol...@gmail.com>]

Hi everyone!
I just wanted to let you know that I've released JCROM 1.3[1], which now
supports lazy loading of child nodes, files, and references [2], plus it
also supports dynamic maps of properties, child nodes, files, and references
[3].

I've updated the User Guide [4] to reflect new features and changes in
release 1.3 [5].

Any comments or feedback welcomed!

Thanks,
Olafur Gauti Gudmundsson

[1] http://jcrom.googlecode.com
[2] http://code.google.com/p/jcrom/wiki/LazyLoading
[3] http://code.google.com/p/jcrom/wiki/DynamicMaps
[4] http://code.google.com/p/jcrom/wiki/UserGuide
[5]
http://code.google.com/p/jcrom/issues/list?q=label%3AMilestone-Release1.3&can=1


Alexander Klimetschek wrote:
> 
> Hi all!
> 
> Looks nice and simple. A colleague of mine at Mindquarry did a jcr- 
> persistence framework that is very, very similar to JPA. I can't  
> remember why he did not use it directly, so he recreated the basic  
> annotation classes like Entity, ID or NamedQuery. Probably because you  
> need some special jcr-compatible extensions.
> 
> Here is an example [4] which would map to /users/*. Note the  
> parentFolder setting of @Entity and also that querying is just like in  
> JPA, but using XPath instead:
> 
> 
> @SerializationName("user")
> @Entity(parentFolder=User.PARENT_FOLDER)
> @NamedQueries({
>      @NamedQuery(name="userByLogin", query="/users/{$userId}"),
>      @NamedQuery(name="allUsers", query="/users/*[local-name() !=  
> 'photos']"),
>      @NamedQuery(name="getUsersForTeam", query="/users/*[jcr:content/ 
> user/teams/item/@reference = /teamspaces/{$teamId}/@jcr:uuid]")
> })
> public class User  {
> 
>      public static final String PARENT_FOLDER = "users";
> 
>      @Id
>      private String login = "";
>      private String pwd = "";
> 
>      public String firstname = "";
>      public String lastname = "";
> 
>      private List<String> skills;
>      private String[] skillsArray;
> 
>      private List<Team> teams;
> 
>      public Group group;
> 
>      .....
> }
> 
> 
> Example of creating/querying objects:
> 
> 
> 	Team team = makeTestTeam();   // new Team() + setting values
>          currentSession().persist(team);
> 
>          List<Team> teams = new LinkedList<Team>();
>          teams.add(team);
>          User user = makeTestUser();  // new User() + setting values
>          user.setTeams(teams);
> 
>          currentSession().persist(user);
> 
>          Session session = sessionFactory_.currentSession();
>          List queryResult = session.query("getUsersForTeam",  
> TEST_TEAM_ID);
> 
>          assertEquals(1, queryResult.size());
> 
> 
> See the framework [1], API classes (eg. Entity) at [2], and the test  
> code for more samples [3]. Note that there is no documentation online  
> apart from the code.
> 
> The implemenation allows for reading/writing full object graphs, ie. a  
> field in an object referencing another object that is also mapped to  
> JCR would get read/written along the way (storing only the object Id  
> in JCR, but preferable would be the JCR path of the referenced  
> object). The JCR structure was custom (it was XMLish, as we stored XML  
> documents directly in a different part of the code), but a Transformer  
> interface abstracts from the special Java <-> JCR mapping [5].
> 
> In the end, we were not so happy with this approach because it seemed  
> to much abstraction from our main API JCR and created yet another  
> caching location (the managed object pool). But we probably added too  
> much abstraction (fully JCR-independent interfaces that were  
> implemented by the annotated objects, yet another Session class,  
> etc.)...
> 
> Here is the executive summary of the pros and cons (which you probably  
> know from OCM or JCROM):
> 
> Advantages:
> + full object graphs supported
> + easy-to-run queries, defined at the object itself
> + code completion for properties
> 
> Disadvantages:
> - pooling = caching needed
> - another hard-to-debug abstraction
> - just a copy of JPA, not using it directly
> 
> Regards,
> Alex
> 
> [1]
> http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/
> 
> [2] API:
> http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/persistence-api/src/main/java/com/mindquarry/persistence/api/
> 
> [3] Test code:
> http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/jcr-persistence/src/test/java/com/mindquarry/persistence/jcr/
> 
> [4] Example annotated class:
> http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/jcr-persistence/src/test/java/com/mindquarry/persistence/jcr/User.java
> 
> [5] "Transformers", mapping Java <-> JCR:
> http://www.mindquarry.org/repos/mindquarry-collaboration-server/trunk/mindquarry-persistence/jcr-persistence/src/main/java/com/mindquarry/persistence/jcr/trafo/
> 
> Am 05.02.2008 um 12:48 schrieb David Nuescheler:
> 
>> hi all,
>>
>> Olafur Gauti Gudmundsson pointed me today to his effort called JCROM
>> (pronounced "Jack-rom"). [1]
>>
>> I am excited about the refreshing, quick and simple annotation based
>> approach [2]
>> and would like to find out what everybody's thoughts are on possibly
>> finding synergies
>> with the ocm framework that we have in Jackrabbit.
>>
>> regards,
>> david
>>
>> [1] http://jcrom.org
>> [2] http://code.google.com/p/jcrom/wiki/TwoMinuteIntro
> 
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com
> 
> 
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Content-Object-Mapping---jcrom.org-tp15288546p17272324.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

Re: Content Object Mapping - jcrom.org

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Fri, May 16, 2008 at 2:07 PM, ogg <ol...@gmail.com> wrote:
> I just wanted to let you know that I've released JCROM 1.3[1], which now
> supports lazy loading of child nodes, files, and references [2], plus it
> also supports dynamic maps of properties, child nodes, files, and references
> [3].

Cool stuff, thanks for the update!

BR,

Jukka Zitting