You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Boni Gopalan (JIRA)" <ji...@apache.org> on 2008/10/04 13:01:44 UTC
[jira] Created: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
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
Affects Versions: 1.5
Reporter: Boni Gopalan
Fix For: 1.5
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.
[jira] Resolved: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting resolved JCR-1784.
--------------------------------
Resolution: Fixed
Both changes are now also in the 1.5 branch. I guess this is everything we need here, so resolving as Fixed.
> 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.
[jira] Updated: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boni Gopalan updated JCR-1784:
------------------------------
Attachment: JCR-1784.bonigopalan.patch
> 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
> Affects Versions: 1.5
> Reporter: Boni Gopalan
> 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.
[jira] Commented: (JCR-1784) OCM:The UUID of the collection
elements changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Reopened: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boni Gopalan reopened JCR-1784:
-------------------------------
> 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.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.
[jira] Updated: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christophe Lombart updated JCR-1784:
------------------------------------
Component/s: jackrabbit-ocm
> 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.
Re: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Posted by Christophe Lombart <ch...@gmail.com>.
If it is not a big deal for you and if it ia a help to keep track on
changes, you can do it. Anyway, thanks for the info in subversion.
christophe
On Thu, Oct 16, 2008 at 12:29, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Thu, Oct 16, 2008 at 12:07 PM, Christophe Lombart
> <ch...@gmail.com> wrote:
> > if you want, I can do it in 1.5
>
> It's no big deal for me to do the merging, and doing so helps me keep
> track of everything that's being included in the release.
>
> But if you like to do the merge then that's fine as well. Note however
> that I'm using the merge tracking feature in Subversion 1.5 to keep
> track of things in the branch, so if you work there make sure that you
> are also using svn 1.5.x and follow a workflow like this:
>
> 0) Checkout the 1.5 branch:
>
> svn co https://svn.apache.org/repos/asf/jackrabbit/branches/1.5
> jackrabbit-1.5<https://svn.apache.org/repos/asf/jackrabbit/branches/1.5jackrabbit-1.5>
> cd jackrabbit-1.5
>
> 1) List all changes in trunk that are waiting to be merged to the branch
>
> svn mergeinfo https://svn.apache.org/repos/asf/jackrabbit/trunk
> --show-revs <https://svn.apache.org/repos/asf/jackrabbit/trunk--show-revs>eligible
>
> 2a) For each change that you want to merge to the branch:
>
> svn merge -c $rev https://svn.apache.org/repos/asf/jackrabbit/trunk
> svn diff # check that everything is ok and modify if needed
> svn commit -m "1.5: Merged revision $rev ($jira)"
>
> 2b) For each change that you do not want to merge to the branch:
>
> svn merge -c $rev --record-only
> https://svn.apache.org/repos/asf/jackrabbit/trunk
> svn commit -m "1.5: Ignore change in trunk"
>
> BR,
>
> Jukka Zitting
>
Re: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Oct 16, 2008 at 12:07 PM, Christophe Lombart
<ch...@gmail.com> wrote:
> if you want, I can do it in 1.5
It's no big deal for me to do the merging, and doing so helps me keep
track of everything that's being included in the release.
But if you like to do the merge then that's fine as well. Note however
that I'm using the merge tracking feature in Subversion 1.5 to keep
track of things in the branch, so if you work there make sure that you
are also using svn 1.5.x and follow a workflow like this:
0) Checkout the 1.5 branch:
svn co https://svn.apache.org/repos/asf/jackrabbit/branches/1.5
jackrabbit-1.5
cd jackrabbit-1.5
1) List all changes in trunk that are waiting to be merged to the branch
svn mergeinfo https://svn.apache.org/repos/asf/jackrabbit/trunk
--show-revs eligible
2a) For each change that you want to merge to the branch:
svn merge -c $rev https://svn.apache.org/repos/asf/jackrabbit/trunk
svn diff # check that everything is ok and modify if needed
svn commit -m "1.5: Merged revision $rev ($jira)"
2b) For each change that you do not want to merge to the branch:
svn merge -c $rev --record-only
https://svn.apache.org/repos/asf/jackrabbit/trunk
svn commit -m "1.5: Ignore change in trunk"
BR,
Jukka Zitting
Re: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Posted by Christophe Lombart <ch...@gmail.com>.
Jukka,
if you want, I can do it in 1.5
BR,
Christophe
On Thu, Oct 16, 2008 at 10:35, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Thu, Oct 16, 2008 at 6:00 AM, Boni Gopalan (BioImagene)
> <Bo...@bioimagene.com> wrote:
> > 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.
>
> OK, I'll make sure sure that all the parts are included in 1.5.
>
> BR,
>
> Jukka Zitting
>
Re: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Oct 16, 2008 at 6:00 AM, Boni Gopalan (BioImagene)
<Bo...@bioimagene.com> wrote:
> 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.
OK, I'll make sure sure that all the parts are included in 1.5.
BR,
Jukka Zitting
RE: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
Posted by "Boni Gopalan (BioImagene)" <Bo...@bioimagene.com>.
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.
[jira] Commented: (JCR-1784) OCM:The UUID of the collection
elements changes on update.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12639948#action_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.
[jira] Commented: (JCR-1784) OCM:The UUID of the collection
elements changes on update.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637177#action_12637177 ]
Christophe Lombart commented on JCR-1784:
-----------------------------------------
Your patch seems good but I'm wondering why you have modified the class AbstractMapperImpl ( see [1]).
It works without this modification and we can leave the code as it is (throw an exception is there is no descriptor).
Are you agree if we don't modify this class ?
[1] Index: src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===================================================================
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor = mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
+ //throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
}
return descriptor ;
}
Index: src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===================================================================
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor = mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
+ //throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
}
return descriptor ;
}
> 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.
[jira] Updated: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boni Gopalan updated JCR-1784:
------------------------------
Attachment: JCR-1784.bonigopalan.patch
> 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
> Affects Versions: 1.5
> Reporter: Boni Gopalan
> 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.
[jira] Resolved: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boni Gopalan resolved JCR-1784.
-------------------------------
Resolution: Fixed
Fixed with the supplied patch
> 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
> Affects Versions: 1.5
> Reporter: Boni Gopalan
> 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.
[jira] Updated: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boni Gopalan updated JCR-1784:
------------------------------
Attachment: JCR-1784.additional.bonigopalan
I also did a bit of code cleanup to remove some repeating code. Basically I saw the approach to update a Node to be :
Locate the node to update and then update it. So I introduce a method that takes in the session, Node to Update and the Object to Update to as parameters and does the updating. This methos is called from the other facade methods that already existed for doing the updates. Eliminated the code duplication.
All the tests are passing.
> 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.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.
[jira] Updated: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boni Gopalan updated JCR-1784:
------------------------------
Attachment: (was: JCR-1784.bonigopalan.patch)
> 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
> Affects Versions: 1.5
> Reporter: Boni Gopalan
> Fix For: 1.5
>
> 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.
[jira] Resolved: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christophe Lombart resolved JCR-1784.
-------------------------------------
Resolution: Fixed
The patch has been applied. thanks and well done ! it was a nice bug :-)
I didn't modify the class AbstractMapperImpl. For me, this modification is not necessary.
I also added unit tests for the annotation support.
Let me know if something is wrong.
> 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.
[jira] Reopened: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Boni Gopalan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boni Gopalan reopened JCR-1784:
-------------------------------
> 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
> Affects Versions: 1.5
> Reporter: Boni Gopalan
> 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.
[jira] Issue Comment Edited: (JCR-1784) OCM:The UUID of the
collection elements changes on update.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637177#action_12637177 ]
clombart edited comment on JCR-1784 at 10/6/08 12:12 PM:
-------------------------------------------------------------------
Your patch seems good but I'm wondering why you have modified the class AbstractMapperImpl ( see [1]).
It works without this modification and we can leave the code as it is (throw an exception is there is no descriptor).
Are you agree if we don't modify this class ?
[1] Index: src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===================================================================
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor = mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
+ //throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
}
return descriptor ;
}
was (Author: clombart):
Your patch seems good but I'm wondering why you have modified the class AbstractMapperImpl ( see [1]).
It works without this modification and we can leave the code as it is (throw an exception is there is no descriptor).
Are you agree if we don't modify this class ?
[1] Index: src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===================================================================
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor = mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
+ //throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
}
return descriptor ;
}
Index: src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java
===================================================================
--- src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (revision 701632)
+++ src/main/java/org/apache/jackrabbit/ocm/mapper/impl/AbstractMapperImpl.java (working copy)
@@ -200,7 +200,7 @@
public ClassDescriptor getClassDescriptorByClass(Class clazz) {
ClassDescriptor descriptor = mappingDescriptor.getClassDescriptorByName(clazz.getName());
if (descriptor==null) {
- throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
+ //throw new IncorrectPersistentClassException("Class of type: " + clazz.getName() + " has no descriptor.");
}
return descriptor ;
}
> 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.
[jira] Assigned: (JCR-1784) OCM:The UUID of the collection elements
changes on update.
Posted by "Christophe Lombart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christophe Lombart reassigned JCR-1784:
---------------------------------------
Assignee: Christophe Lombart
> 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
> 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.