You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Martin Zdila <m....@mwaysolutions.com> on 2008/01/27 18:43:02 UTC
M-Way OCM Tool (full)
... sorry, but previous post was accidental :-)
again...
Hello
I'd like to open our lightweight but powerful OCM solution. Major
highlights/features are:
- saving/loading hierarchy of objects
- saving/loading by one call (eg. MyObject myObject = (MyObject)
ocmTool.load(node); ocmTool.save(someOtherObject))
- mapping defined by Java 5 annotations
- supports arrays, collections, maps (with string key); values can be
primitives, objects, references, binary data
- supports nodes with/without UUID
- uses type registry for node to class mapping
- simple class registration (by one call)
- very simple but powerful control of cascading (by overriding save/get
methods)
- OcmTool has only cca 1300 lines of code
- TODO: improve documentation, write some examples, extend unit tests
We are happily using this tool in our project.
My question is how is the best way to share it. WIKI? SourceForge.net? Is
anybody interested?
Thanks in advance
--
Martin Zdila
CTO
M-Way Solutions Slovakia s.r.o.
Letna 27, 040 01 Kosice
Slovakia
tel:+421-908-363-848
mailto:m.zdila@mwaysolutions.com
http://www.mwaysolutions.com
xmpp:zdila@jabbim.sk (Jabber)
skype:m.zdila
Re: M-Way OCM Tool (full)
Posted by Alex Lukin <lu...@stu.cn.ua>.
Monday 28 January 2008 15:01:01 Christophe Lombart написав:
[skip]
> > 2. OCM must check class and class versions while loading of saving nodes.
> > What
> > to do if something goes wrong? I decided to take "best effort" strategy.
> > We
> > map what we can and leave data untouched if in doubt. and yes, we
> > strictly warn developer and admin.
>
> Can you give more details ?
There's 2 cases.
1st, we read node already created by some other software and our class is not
100% compatible with node structure, different version for example. Our class
misses few fields or has few additional. What to do? I do not want just throw
exception and panic. Engine must try to map what it can and send warnings to
logs.
2nd, our piece of soft just slightly changed and tries write operation on
existing node. Should we add new properties new class have? I guess yes.
Should we delete properties that left? I guess no without explicit command.
Again, no fatal exceptions, just logs.
That happens very often not because developers always break things. There 2
reasons for it: 1. No strict type checking for JCR nodes. 2. Recursion. We
can add subnodes or links and we usually do.
> > 3. OCM must have possibility to find typed objects by parameters and by
> > types.
>
> I don't understand please can you give more details ?
>
Well, imagine you have NewsPosting class with date, subject and text
properties. Node's type is NewsPosting. What I want is auto-generated
finders like findByDate(), findBySubject for fields I mark as search keys.
Those finders must search strictly NewsPosting nodes, not Votings or
ForumPostings.
Looking at changes with JSR 283 about query languages, finders might be very
helpful for those who does not want to learn a couple of additional query
languages.
[skip]
>
> > A couple of words about recursion. There are 2 different apects. First,
> > you
> > may have class that contains link to itself. It is very convinient for
> > things
> > like categories and so on. But this is infinite recursion and I use
> > "deep" property to make it finite.
>
> What is a deep property. We have the same problem but is it managed
> differently (with a small cahe)
Just simple example of content. Some classificator site has article
categories. It is obviously tree. Our Category class is recursive itself
because contains "List<Category> subcategories" field. But how deep must be
this hierarchy? I just say that max is 10 and my OCM knows that it does not
go into recursion deeper then 10 calls.
>
> > Second, when class has properties as class
> > instance that has properties as class instance etc... We must go down to
> > simple types and make nodes for all of it. May be good solution id
> > annotation
> > inheritance for this case. If some property marked as persistent so all
> > stuff
> > that containde in property myst be marked as persistent.
>
> I'm not sure if I understand correctly but in OCM we are managing this with
> BeanDescriptors & CollectionDescriptors.
What I'm trying to implement is something like that.
I write:
@JCRProperty
MyBean beanField
and all properties of MyBean class with getters/setters inherit this markup if
not said @JCRnomap. Well, It needs to be tested. Right today I found more
problems with this then advantages. But generally speaking OCM must be
recursive by all means.
About path, IDs and ORM influence. After reading of previous discussion I
believe we have to think completely different way with tree data structures
like JCR. Full path is not absolutely correct instance identificator because
we map trees, not tables.
For instance, node L1 has subnode L2 for first run. Then we add subnode L3 to
L2. Is path to node L1 changed on second run? No. Is mapping changed? I
think, yes. What is interesting in this situation, that JCR does not have
restriction for us just to add subnode antime.
There's one beatiful thing with JCR: recursion which makes big difference
between JCR and relational databases.
I think about dynamical generation of
mapping. It's easy with languages like Perl where everything typed dynamicaly.
Byt anyway, we can make everything just java,lang.String :) OK, this is
subject of separate academical discussion :) (this is joke, hope you guys
understand)
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: M-Way OCM Tool (full)
Posted by Christophe Lombart <ch...@gmail.com>.
Alex,
Thanks for your comments. You are welcome to create new Jira issues & send
us patches.
Your help will be very appreciated.
Here is my comments :
On Jan 28, 2008 1:05 PM, Alex Lukin <lu...@stu.cn.ua> wrote:
> Monday 28 January 2008 13:07:25 Christophe Lombart написав:
> >
> > There is also the annotation support in Jackrabbit OCM.
> > ... but ok the doc is missing :-)
> >
> Well, what if good OCM in my humble opinion? Yes, documented with
> examples! :)
>
> 0. It must work recursive because we work with tree.
OCM is recursive.
>
>
> 1. It does not demand a lot of efforts or takes no time for writing
> mappings.
> No long XMLs. Annotations just OK, my be even annotations that available
> at
> run-time. Developer just registers classes with required annotations and
> system knows how to work with them.
>
It is working like this now.
>
> 2. OCM must check class and class versions while loading of saving nodes.
> What
> to do if something goes wrong? I decided to take "best effort" strategy.
> We
> map what we can and leave data untouched if in doubt. and yes, we strictly
> warn developer and admin.
>
Can you give more details ?
>
> 3. OCM must have possibility to find typed objects by parameters and by
> types.
>
I don't understand please can you give more details ?
>
> 4. OCM must have transactional manager just like in JPA or EJB 3.0
>
It is possible to use the Tx Jackrabbit stuff. We are reviewing the Spring
module integration in order to have a more flexible tx support.
Other solutions are welcome.
>
> 5. JCR path shoud never be mapping parameter. This is runtime parameter
> because one can retrive same data types from different places.
see the discussion here :
http://www.mail-archive.com/dev@jackrabbit.apache.org/msg09960.html
>
>
>
>
> A couple of words about recursion. There are 2 different apects. First,
> you
> may have class that contains link to itself. It is very convinient for
> things
> like categories and so on. But this is infinite recursion and I use "deep"
> property to make it finite.
What is a deep property. We have the same problem but is it managed
differently (with a small cahe)
> Second, when class has properties as class
> instance that has properties as class instance etc... We must go down to
> simple types and make nodes for all of it. May be good solution id
> annotation
> inheritance for this case. If some property marked as persistent so all
> stuff
> that containde in property myst be marked as persistent.
I'm not sure if I understand correctly but in OCM we are managing this with
BeanDescriptors & CollectionDescriptors.
Re: M-Way OCM Tool (full)
Posted by Alex Lukin <lu...@stu.cn.ua>.
Monday 28 January 2008 13:07:25 Christophe Lombart написав:
>
> There is also the annotation support in Jackrabbit OCM.
> ... but ok the doc is missing :-)
>
Well, what if good OCM in my humble opinion? Yes, documented with examples! :)
0. It must work recursive because we work with tree.
1. It does not demand a lot of efforts or takes no time for writing mappings.
No long XMLs. Annotations just OK, my be even annotations that available at
run-time. Developer just registers classes with required annotations and
system knows how to work with them.
2. OCM must check class and class versions while loading of saving nodes. What
to do if something goes wrong? I decided to take "best effort" strategy. We
map what we can and leave data untouched if in doubt. and yes, we strictly
warn developer and admin.
3. OCM must have possibility to find typed objects by parameters and by types.
4. OCM must have transactional manager just like in JPA or EJB 3.0
5. JCR path shoud never be mapping parameter. This is runtime parameter
because one can retrive same data types from different places.
6. My strategy for light OCM is: class is typed node, simple class field is
property, class instance field is subnode and so on recursively. And yes, I
just ignore JCR node type mechanics because it is too inconvinient.
A couple of words about recursion. There are 2 different apects. First, you
may have class that contains link to itself. It is very convinient for things
like categories and so on. But this is infinite recursion and I use "deep"
property to make it finite. Second, when class has properties as class
instance that has properties as class instance etc... We must go down to
simple types and make nodes for all of it. May be good solution id annotation
inheritance for this case. If some property marked as persistent so all stuff
that containde in property myst be marked as persistent.
And few words about content modeling. Some guys like to write XML for data
modeling, it's OK but not good because you can not model things like
<mynewsdir><$year><$month>... There's no defines of vars and no possibility
for dynamic tress. That's why my JAXB based solution not good for OCM.
May be OCM annotated classes will be better and more clean for data modeling?
And finally. I do not see any advantages of JCR comparing to traditional
database without good and ease to use OCM and content modeling tools. My
expirience says: JCR is just more time for development without any
significant pluses.
Hope, my comments will be helpfull for users and develoipers.
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: M-Way OCM Tool (full)
Posted by Christophe Lombart <ch...@gmail.com>.
On Jan 28, 2008 11:23 AM, Alex Lukin <lu...@stu.cn.ua> wrote:
>
>
> Current OCM from jackrabbit is not yet mature and uses old-fashion xml
> descriptors that I dislike. Your solution sounds like old good POJOs and
> it
> is good news.
There is also the annotation support in Jackrabbit OCM.
... but ok the doc is missing :-)
>
>
> So your message is very interesting. I'd like to see code and help with
> development.
> --
> SY, Alex Lukin
> RIPE NIC HDL: LEXA1-RIPE
>
Re: M-Way OCM Tool (full)
Posted by Alex Lukin <lu...@stu.cn.ua>.
Sunday 27 January 2008 19:43:02 Martin Zdila написав:
>
> Hello
>
> I'd like to open our lightweight but powerful OCM solution. Major
> highlights/features are:
[skip]
Sounds great!
I developed my own OCM solutions basd on JAXB technology and Import/Export XML
features of JCR. It works but there're difficulties with JAXB as base
technology because it is not so convinient as it should be. Now I'm trying to
build something simple and fast, annotation based, that could be used just as
runtime base classes for autoasve/autoretrive nodes. Anyway both solutions
too raw to be published but I've got some expirience and know what is good
and what is bad at least :)
Current OCM from jackrabbit is not yet mature and uses old-fashion xml
descriptors that I dislike. Your solution sounds like old good POJOs and it
is good news.
So your message is very interesting. I'd like to see code and help with
development.
--
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE
Re: M-Way OCM Tool (full)
Posted by Martin Zdila <m....@mwaysolutions.com>.
Hello
I've published M-Way OCM to SVN at http://code.google.com/p/m-way-ocm/
Feel free to check it out and play with it but there are still missing:
- documentation (javadoc)
- examples
- updated testcase
I'll try to bring above mentioned TODOs to usable state as soon as possible,
hopefully this week.
Stay tuned.
> Hello
>
> I'd like to open our lightweight but powerful OCM solution. Major
> highlights/features are:
> - saving/loading hierarchy of objects
> - saving/loading by one call (eg. MyObject myObject = (MyObject)
> ocmTool.load(node); ocmTool.save(someOtherObject))
> - mapping defined by Java 5 annotations
> - supports arrays, collections, maps (with string key); values can be
> primitives, objects, references, binary data
> - supports nodes with/without UUID
> - uses type registry for node to class mapping
> - simple class registration (by one call)
> - very simple but powerful control of cascading (by overriding save/get
> methods)
> - OcmTool has only cca 1300 lines of code
> - TODO: improve documentation, write some examples, extend unit tests
>
> We are happily using this tool in our project.
>
> My question is how is the best way to share it. WIKI? SourceForge.net? Is
> anybody interested?
>
> Thanks in advance
--
Martin Zdila
CTO
M-Way Solutions Slovakia s.r.o.
Letna 27, 040 01 Kosice
Slovakia
tel:+421-908-363-848
mailto:m.zdila@mwaysolutions.com
http://www.mwaysolutions.com
xmpp:zdila@jabbim.sk (Jabber)
skype:m.zdila
Re: M-Way OCM Tool (full)
Posted by Martin Zdila <m....@mwaysolutions.com>.
hhanks
i'll check google code
On Mon 28. January 2008 05:41:50 Big Z wrote:
> how about the performance?
i haven't measured it but there should be no time consuming code.
> I think googlecode is one good choice.
--
Martin Zdila
CTO
M-Way Solutions Slovakia s.r.o.
Letna 27, 040 01 Kosice
Slovakia
tel:+421-908-363-848
mailto:m.zdila@mwaysolutions.com
http://www.mwaysolutions.com
xmpp:zdila@jabbim.sk (Jabber)
skype:m.zdila
Re: M-Way OCM Tool (full)
Posted by Big Z <jg...@gmail.com>.
how about the performance?
I think googlecode is one good choice.
On 1/28/08, Thomas Mueller <th...@gmail.com> wrote:
> Hi,
>
> This tool sounds very interesting!
>
> > the best way to share it.
>
> I have used SourceForge.net and Google Code
> (http://code.google.com/hosting). I found Google Code simpler and
> quicker, but SourceForge has more features. It doesn't really matter,
> you can switch later on. For more options:
> http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities
>
> Regards,
> Thomas
>
--
Best Regards!
Re: M-Way OCM Tool (full)
Posted by Thomas Mueller <th...@gmail.com>.
Hi,
This tool sounds very interesting!
> the best way to share it.
I have used SourceForge.net and Google Code
(http://code.google.com/hosting). I found Google Code simpler and
quicker, but SourceForge has more features. It doesn't really matter,
you can switch later on. For more options:
http://en.wikipedia.org/wiki/Comparison_of_free_software_hosting_facilities
Regards,
Thomas