> To what object will it map the content stored in the repository? Like, > beans, Map-s?
to POJO with attributes like simple values, collections, .... and associations to others POJO. > > And most importantly: when will it create those object? Like, every time > a query has issued? At least when the request is made on the PK (the path) :-) Concerning the queries, more analysis are required. we just started a proposal and a small proof of concept. Just a couple of comments on what I red in this thread : * To be honnest, we (the Graffito team) don't think about the cache because Jackrabbit has already a internal cache that can be used in a lot of case and caching was plan for later. * I think it should be possible to find an open source "cache" project that can help us (JCS, Oscache, ...) * Concerning the synchronisation between the cache and the repo : it is a classical issue with ORM mapping. I'm not sure that complex mechanism will be usefull. If you decide to use some ORM layer and try to update the repo via another way, don't cache the objects that can be update outside this Object layer. OJB has this kind of features. * Concerning the heavy loading of some CMS objects, why not to use some proxies in order to make lazy loading. Again it is used often in ORM mapping tools and I think it should be possible to implemented in a O-JCR mapping tools. * I'm very happy to see this discussion here and I would like to group all volonteers who want to build this kind of tools. If Jackrabbit it not the right place to discuss on that (and build this tools), you are welcome to join us on the Graffito mailing list. Again Graffito is not a competitor to Jackrabbit. There are complementary tools. then, start together a project and later we can see where to host this one in the ASF world. a small proposal can start with a simple features list. The object caching is important but also other features like lazy loading, the mapping config, matching node type and javabeans, ... I think it is not a one man job. Thanks, Christophe > > -- > Best regards, > Daniel Dekany > >
