Re: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
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 [EMAIL PROTECTED]wrote: Hi, On Thu, Oct 16, 2008 at 12:07 PM, Christophe Lombart [EMAIL PROTECTED] 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.5https://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-revseligible 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.
Hi, On Thu, Oct 16, 2008 at 6:00 AM, Boni Gopalan (BioImagene) [EMAIL PROTECTED] 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.
Jukka, if you want, I can do it in 1.5 BR, Christophe On Thu, Oct 16, 2008 at 10:35, Jukka Zitting [EMAIL PROTECTED]wrote: Hi, On Thu, Oct 16, 2008 at 6:00 AM, Boni Gopalan (BioImagene) [EMAIL PROTECTED] 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.
Hi, On Thu, Oct 16, 2008 at 12:07 PM, Christophe Lombart [EMAIL PROTECTED] 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
[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.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
RE: [jira] Commented: (JCR-1784) OCM:The UUID of the collection elements changes on update.
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:[EMAIL PROTECTED] 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-tabpanelfocusedCommentId=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.
[ https://issues.apache.org/jira/browse/JCR-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] 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.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.
