jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Modrzyk <nicolas.modr...@macnica.com>
Subject Re: Persisting beans in the content repository
Date Fri, 13 Oct 2006 16:34:14 GMT
Hi Christophe,

Thank you for your long and detailed answer.

> Concerning configuration :
> Our configuration contains information on the mapping strategy to use
> per persistence class.
Yes. That is exactly what we managed to avoid. Give a bean, give a  
node, pass it to the coder, and save the node is all you need to do.  
As I said, simplicity was our target.

> I think mapping info is required to customise mapping strategies and
> increase performance (eg. with caching & proxies definition). How to
> load or save an object graph without configuration mapping info ? it
> should be possible but you have only one mapping strategy in this
> case. Furthermore, your content repo structure depends on your
> "default" mapping strategy.  How your tools is supporting interface &
> inheritance ? how to map a java bean field into a jcr property having
> another name ? How to make value conversion ?
In all those technical cases, you use Graffito. In the current bean  
coder implementation, you can extend easily how you want the storage  
to be done, but this forces to write a java class.

> Anyway, we are interesting by a contribution to use annotations and
> why not we can define a default mapping strategy if the peristent
> class is not present in the config info. Any kind of contribution in
> this area is welcome.
What's the overhead in that particular case ? Can you expand on how  
you would see annotations for a default mapping strategy ? (sad me  
though, I am forced to stick with 1.4 ...)

> Concerning the reference node present in the API :
> It was a long discussion in the Graffito team : either the path (or
> another kind of node id ) is defined in the object to persist or the
> persistence API gives to possibility to defined the node path to use.
> Right now, we are following what many ORM are doing : define the path
> in the object to persist. why is it a problem to work like this ?
Errr ... because not everything is converted to a bean in my case. I  
have a configuration workspace for the CMS, this workspace has  
sections, clearly defined. Some section need beans, some need list of  
beans, some map of beans, some are just indeed plain beans.
I don't want the ORM to tell me how I should do things in this case.  
If it does, I loose all the structure, all the compatibility ...

>> could that be fitted in Graffito by any means ?
> Configuration : Yes, if we define a default mapping strategy. It could
> be interesting in some cases for lazy developers :-)

Perfect, I am a lazy developer !! \(^ ^)/

> What do you mean by creating bean from the repo ? Is it not a "simple"
> retrieve from the repo to populate some beans ? if true, yes of
> course. We are also supporting lazy loading (optional) and other
> techniques to maximize performances.
> With our OCM tools, you can insert, update, delete and retrieve beans
> from a JCR repo. Like I said on TSS, we want to make abstraction on
> the JCR without losing its flexibility.
Nice, then I will definitely have a try again.

>> would that be committed in the contrib section ?
> Still under discussion. We will see :-)
Really hope it is. One of this kind of tool has to make it to  
Maybe the contribution section in jackrabbit should go a few steps  
further as well. We really need those kind of tools to make the  
JSR-170 take off.

One last quick question: what's the easiest way to integrate (just)  
the ORM section of graffito in my CMS ?

Thanks for all again. Really appreciate the details of this  


View raw message