[
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.
