jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boni Gopalan \(BioImagene\)" <Bon...@bioimagene.com>
Subject RE: OCM:To Path or Not to Path
Date Wed, 08 Oct 2008 07:16:07 GMT
Let me take a challenge I am facing right now to give the context of why identities other than
UUID is important - may be this is something specific to the OCM interpretation.

I mapped Foo , with mix:referenceable and by specifying an UUID field on the the bean. I saved
an instance of Foo. After some time I archived that Instance (A normal enterprise requirement).
 After some more time user requests a restore.  Now if I restore using the same OCM layer
I am going to get a different UUID.  It is not desirable at all.  I would like the state of
the object to be restored just as it was before: including the jcr:uuid.

So the simple notion of UUID being unique alone is not sufficient.  What about a notion of
UUID : <scope = "usecurrentifprovided">?

OCM fully acknowledges this and has provided the notion of "id" through "id=true" attribute.
 I feel, for the completeness of such a notion we need the ability to attach an ID generator
with the intelligence of not generating a new ID if one is provided.


-----Original Message-----
From: Aleksei Lukin [mailto:lukin@stu.cn.ua] 
Sent: 08 October 2008 12:20
To: users@jackrabbit.apache.org
Subject: Re: OCM:To Path or Not to Path

Hi, all!

Tuesday 07 October 2008 13:30:30 Boni Gopalan (BioImagene) написав:
> IMO the only characteristics that can uniquely identify an object is the
> path.  So did the 'identity' of the object change when it moved from
> /drafts node to /final node? ; I feel it did.  If we map the transaction to
> ORM what just happened is a table to table move.

Well it is a question. JCR does not change node's UUID on move(). And we can not speak about
path change as move to another table because object could be found by the same search 
expression if does not contain path attribute. IMHO entire JCR workplace is one table and
path is just some unique attribute. We can not have 2 objects with same path and we can 
not have 2 objects with same UUID too. 
Let's speak about trivial filesystem and trivial file. If we move some file, and then make
change to it, we got the same object but changed. If we copy file and then change the 
original we got 2 different objects. How can we get acces to file? OK, only by path at the
trivial filesystem. But if we have some kind of indexes, we can get access trough 
index that will not change on file move and change on copy. At the point of index path is
just attribute. It is the way to keep reference integrity.

So why UUID is so important and quite better then path? The answer is reference integrity
that possible with UUID and not possible with path.
That's why I said that path is not cosistent as primary key.

> There seems to be a fundamental misunderstanding in the way Christophe is
> defining the OCM structure and the way I have understood it.  I do not see
> that current implementation cares too much about the identity specification
> through an uuid.  It likes a custom identity definition supplied by the
> application.  That could be genesis of fields specified as id fields.  I
> completely agree with this approach.  UUID: is a luxury provided by
> jackrabbit and OCM need not leverage on it alone. If that is so do we need
> to provide the notion of a Sequence Generator from OCM? : Through the
> annotation and through the mapping file.  This would be useful for the
> applications to define a domain object as 'one with an id'.
> <sequence-descriptor name = "FooSeq" type="String"/>
> <class-descriptor className="com.bioimagene.iii.dms.domain.Foo">
> 	<field-descriptor fieldName="name" jcrName="name" jcrType="String"/>
> 	<field-descriptor fieldName="id" id="true" sequence="FooSeq"/>
> </class-descriptor>

Why sould I do such things if I just can add mix:referenceable to node and enjoy unique key
of object in the entire Universe? :)
I can find my object even it moves to another JCR.
If some JCR implementation does not support UUIDs, J2SE does. Just add UUID.randomUUID().roString()
to OCM code.
Besides it, current OCM code contains a lot of code thet depends on UUID for references support.
Do we need references? Sure, we do.

> This will help the current implementation philosophy that uses id values to
> resolve the names of same name siblings.  I do not know for sure but such a
> feature might straighten a few other wrinkles that I feel I felt when using
> OCM.

Same name siblings will pass out of the scene because according to last year discussions SNS
are not recommended for use and are kept  only for XML inport/export operations.
At  JCR point of view SNS is just nodes with different path.

> Thanks
> Boni
SY, Alex Lukin

View raw message