jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boni Gopalan \(BioImagene\)" <Bon...@bioimagene.com>
Subject RE: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Date Thu, 16 Oct 2008 04:00:20 GMT
I had submitted two patches on this issue.  The first one was incomplete
as it was not applying the same UUID interpretation to
same-name-siblings other than collection elements. I feel both the
patches should be applied to the same versions to provide a consistent
interpretation.  I am not sure which was the cut off date that Jukka
decided for 1.5 release.  I feel the first patch file was applied to the
1.5-SNAPSHOT.

-----Original Message-----
From: Christophe Lombart (JIRA) [mailto:jira@apache.org] 
Sent: 16 October 2008 01:47
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1784) OCM:The UUID of the collection
elements changes on update.


    [
https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.p
lugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639948#a
ction_12639948 ] 

Christophe Lombart commented on JCR-1784:
-----------------------------------------

Done. Thanks for your contribution.  

Do you want to see the latest path in the branch 1.5 ? 
I'm not sure that is critical for the release 1.5. 



> OCM:The UUID of the collection elements changes on update.
> ----------------------------------------------------------
>
>                 Key: JCR-1784
>                 URL: https://issues.apache.org/jira/browse/JCR-1784
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-ocm
>    Affects Versions: 1.5.0
>            Reporter: Boni Gopalan
>            Assignee: Christophe Lombart
>             Fix For: 1.5.0
>
>         Attachments: JCR-1784.additional.bonigopalan,
JCR-1784.bonigopalan.patch
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> On ocm.update transaction, the  Current implementation of
DefaultCollectionConverterImpl recreates the colleciton-element nodes if
there is no id field specificaiton.  This is completely valid for
majority of the cases.  But I came across a case where the colleciton
element has a uuid field.  In this case also what is happening with the
current implementation is that it drops all the elements from the old
collection-elements and recreates the new ones.  The major flip side is
that now I am left with brand new UUIDs.  I think we should address the
uniqueness characteristics specified through UUID also while mapping
colleciton elements.
> I have a patch and a TestCase to verify the same.  I have implemented
it only for the digester.  If people feel the approach is right I will
work out an annotation based testcase as well.  I do not think it is
going to fail even with annotations.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message