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