jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksei Lukin <lu...@stu.cn.ua>
Subject Re: OCM:To Path or Not to Path
Date Wed, 08 Oct 2008 06:50:25 GMT
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
>
Thanks,
-- 
SY, Alex Lukin
RIPE NIC HDL: LEXA1-RIPE

Mime
View raw message