jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christophe Lombart" <christophe.lomb...@gmail.com>
Subject Re: OCM: path as primary key is questionable
Date Thu, 20 Mar 2008 09:21:09 GMT
Sorry for the delay. Here is a couple of comments

On Tue, Mar 18, 2008 at 9:23 AM, Alex Lukin <lukin@stu.cn.ua> wrote:
> Hi!
>  Sunday 16 March 2008 22:32:55 Christophe Lombart написав:
> > >  So question is: why not to use UUID as primary key for OCM? In my
>  > > opinion it is only one reliable key in JCR. OCM code may just force all
>  > > OCM nodes to have jcr:uuid property and relay on it.
>  >
>  > For me, this is not a good idea because UUID is not mandatory in JCR.
>  OCM is not mandatory by JCR too but this fact does not stop you from development. :)
>  UUID is mentioned many many times in JSR-170 so it is madatory in JCR but optional for
some nodes you do not care of.
>  Referencial integrity is not possible without UUID. Implementation of JCR is not possible
without UUID.

If you are using nt:unstructured type, this is not necessary to use UUID.

> > Furthermore, you are forcing to apply the mixin type
>  > "mix:referenceable" to each node.
>  Is it big deal? In your former implementation you forced ocm:discriminator mixin type
for nodes with ugly type registration code.

Other solutions are welcome to fix it, depending on your use cases,
ocm:discriminator is not always mandatory (see in 1.5 snapshot).

OCM supports inheritance and interfaces. In such situation, a
discriminator is usefull. This is often used in ORM frameworks.

>  Node with mix:referenceable is quite better because it forces referncial integrity of
node and developer can be sure that references
>  to OCM nodes will be OK. What's bad wiht it? Imagine I move some node from user's home
to public area. All references made to this node
>  before move will be OK after move.

I never said that UUID is bad. I would like to keep it optional in OCM
as it is in the JCR spec.
That's all. If you want to use UUID in your pojos, that's possible
with the current OCM implementation.

>  > I'm not sure this is a good idea for all use cases.
>  I can tell you 5 uses cases where path is very questionable idea causing incosistences.
Tell me one use case where UUID is bad. :)
>  And by the way, UUID operations are 25-50% faster then path operations. Furthermore,
UUID can be used as unique instance ID independent
>  of node location. Fetching by UUID you can always return correct path for oubject. You
can place object where you want.

ocm.getObject(myUUID) is not suffisant ?

>  >
>  PS.
>  Dear Christophe! Please do not think I criticize your implementation because I don't
like it. There's anotgher solutions but I use yours.
>  I just want make it better. Unfortunately, it takes time to catch up with code and I
can't send you patch right today to check idea with UUID.

You are welcome. I do not feel at all attacked :-). That's very
interesting to exchange ideas to improve the OCM framework.

My current goal for a couple of month is not add new feature. I would
like to simplify some aspects. So, all comments, patch, questions are

In the same idea, there was a  discussion on making the path optional
: http://www.mail-archive.com/dev@jackrabbit.apache.org/msg09960.html

View raw message