jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boni Gopalan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Date Tue, 07 Oct 2008 06:46:45 GMT

    [ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637396#action_12637396

Boni Gopalan commented on JCR-1784:

We seem to be going back and forth with this AbstractMapperImpl change I made.  I had a problem
with that throws clause and unfortunately I need to spend some time to recreate the test scenario
that required me to change the implementation.  If I remove the throws clause I know that
a few of my application testcases will fail.  I will work out a testcase that I hope will
convince you the need to remove that throws.  Till then I completely am with you on keeping
AbstractMapperImpl as is.

I came across a similar issue with update elsewhere.  Consider same name sibling nodes with
UUID specified.  Though these are not part of a collection it very well act as those are collection
elements.  However since the code handles the mapping from directly within ObjectConverterImpl's
update method we need to make that update as well intelligent enough to decipher uniqueness
through UUID.  I have a patch and I will add it to this discussion.

> 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
>            Reporter: Boni Gopalan
>            Assignee: Christophe Lombart
>             Fix For: 1.5
>         Attachments: 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.

View raw message