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
jackrabbit.
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
conversation.
Niko
