OCM:Supporting nested properties for the FilterImpl
The Filter is a nifty interface that allows hassle free construction of
JCR query strings through a Criterion() like methods. The default
implementation does a remarkably accurate job of building queries that
are one level deep. It would be great if the queries can be any level
deep so that one can fetch back any specific 'Object' representation of
a node or a property.
Eg.
Foo{
String id;
ListBar myBar;
}
Bar{
String id;
String name;
}
Filter(Foo.class); [Not exactly but you get the idea!]
Filter.addEqualsTo(myBar[].name, CA's Pub Pub);
Ocm.getObjects(Filter) , fetches all the Foos with a nested property
name=CA's Pub
Any thoughts? Is it possible with the current API?,
Thanks
Boni
Boni Gopalan
Manager Engineering
BioImagene, Pune
+91-206-609-6579(O)
+91-992-369-9356(C)
RE: OCM:Supporting nested properties for the FilterImpl
The Mapping file gives a good handle on guessing what the equivalent
node or property name is. I think the current mapping file has all the
information needed to do an OGNL like traversing of the Nodes. Will try
out a testcase to understand the challenges.
-Original Message-
From: Christophe Lombart [mailto:[EMAIL PROTECTED]
Sent: 17 October 2008 12:26
To: dev@jackrabbit.apache.org
Subject: Re: OCM:Supporting nested properties for the FilterImpl
At present, this not possible but I think it should be nice to
implement
it.
See the issue http://issues.apache.org/jira/browse/JCR-878 (see the
latest
point in this issue). We can split this issue into smaller ones .
On Fri, Oct 17, 2008 at 08:01, Boni Gopalan (BioImagene)
[EMAIL PROTECTED] wrote:
The Filter is a nifty interface that allows hassle free construction
of
JCR query strings through a Criterion() like methods. The default
implementation does a remarkably accurate job of building queries that
are one level deep. It would be great if the queries can be any level
deep so that one can fetch back any specific 'Object' representation
of
a node or a property.
Eg.
Foo{
String id;
ListBar myBar;
}
Bar{
String id;
String name;
}
Filter(Foo.class); [Not exactly but you get the idea!]
Filter.addEqualsTo(myBar[].name, CA's Pub Pub);
Ocm.getObjects(Filter) , fetches all the Foos with a nested property
name=CA's Pub
Any thoughts? Is it possible with the current API?,
Thanks
Boni
Boni Gopalan
Manager Engineering
BioImagene, Pune
+91-206-609-6579(O)
+91-992-369-9356(C)
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.
RE: [jira] Resolved: (JCR-1804) Added the functionality to Map and Manage Type Enum
Agree with you. This Only needs to be in the trunk. Thanks! -Original Message- From: Christophe Lombart (JIRA) [mailto:[EMAIL PROTECTED] Sent: 16 October 2008 02:11 To: dev@jackrabbit.apache.org Subject: [jira] Resolved: (JCR-1804) Added the functionality to Map and Manage Type Enum [ https://issues.apache.org/jira/browse/JCR-1804?page=com.atlassian.jira.p lugin.system.issuetabpanels:all-tabpanel ] Christophe Lombart resolved JCR-1804. - Resolution: Fixed Done. Thanks for the patch. I have only applied on the head (1.6-SNAPSHOT). I think this is not critical for the release 1.5. What do you think about that ? Added the functionality to Map and Manage Type Enum --- Key: JCR-1804 URL: https://issues.apache.org/jira/browse/JCR-1804 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-ocm Affects Versions: 1.6.0 Reporter: Boni Gopalan Assignee: Christophe Lombart Priority: Minor Fix For: 1.6.0 Attachments: JCR-1804.bonigopalan.patch OCM API does not come with a mapper that can map Type Enum. I have added this functionality. Attached patch has test cases that tests the feature for Simple fields and Collection fields (For both anotations and digester based implementations) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
