Re: jcr:deref in predicate with jcr:contains
Hi, On Mon, May 25, 2009 at 18:47, Dan Diephouse dan.diepho...@mulesource.com wrote: I've made good progress on JCR-977. I now have a working implementation, although a bit rough around the edges. One of the use cases I wanted to support was using jcr:contains and jcr:deref in a predicate, but I'm not sure how the syntax should look. I came up with the following: //*[jcr:contains(people/jcr:deref(@worksfor, '*'),'ballmer')] (This builds off from the DerefTest. Given, this isn't an actual query that you're likely to do as it will return /testroot in the unit tests, which doesn't have a high semantic value for this case. But it is useful I swear :-)) I suppose that syntax works, but it seems like it'd be useful to be able to drill down to further nodes. e.g. //*[people/jcr:deref(@worksfor, '*')/jcr:contains(.,'ballmer')/foo/@bar] This syntax doesn't make sense as jcr:contains isn't really a path location. right, the return type of jcr:contains() is boolean and not a node set. What I really need is support for predicates in predicates! Does XPath account for any of these types of scenarios? well, XPath in general would allow predicates in predicates, but jackrabbit does not support it. e.g. //*[people/jcr:deref(@worksfor, '*')[jcr:contains(.,'ballmer')]/foo/@bar] is valid XPath syntax, but would require quite some enhancements to the abstract query tree in jackrabbit. Or would the XPath way be more like: //*[jcr:contains(people/jcr:deref(@worksfor, '*'),'ballmer') and people/jcr:deref(@worksfor, '*')/foo/@bar] that's probably easier to support with the current jackrabbit implementation. regards marcel Cheers, Dan -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
On Fri, Apr 24, 2009 at 9:27 AM, Marcel Reutegger
marcel.reuteg...@gmx.netwrote:
Hi,
On Wed, Apr 22, 2009 at 21:57, Dan Diephouse
Wondering if I
have some freedom here. Otherwise it's going to end up a big ugly it
looks
like...
as an alternative we could try to add a new class, which leaves
RelationQueryNode untouched. but on the other hand that will introduce
a new method in QueryNodeVisitor. so we're back to square one.
I guess, no matter what we do there's always a chance that existing
code will break.
I was able to change this with just a small amount of breakage...
getRelativePath() now returns PathQueryNode instead of Path. I don't think
there is anyway around this... I doubt anyone is even using this API
oustide of jackrabbit, but I could of course be wrong.
Sorry this has taken so long to get on, but it's now top priority for me. I
was able to construct a QueryNode model alright, but now I'm pondering the
actual query itself. Hoping maybe you can confirm a few things.
When I do the query /people//jcr:deref(@worksfor, '*')[...@ceo = 'McNealy'] I
get a lucene query like:
+(_:PROPERTIES:1:ceo[McNealy
_:PROPERTIES:1:ceo[1:McNealy)
+DerefQuery(DescendantSelfAxisQuery(+ChildAxisQuery(+ChildAxisQuery(_:PARENT:,
{}testroot), {}people), _:PROPERTIES_SET:1:worksfor, 1), null, 1:worksfor)
Now switching this up to /people//*[jcr:deref(@worksfor,
'*')/@ceo='McNealy'] I'm wondering what the query should look like (is there
an API for testing these queries quickly/easily by just typing in a query
string?). I'm a bit stuck as I kind of need to do the opposite of the
DerefQuery - instead of returning the bitset of all the UUIDs in the
@worksfor property, I need the UUIDs of all the nodes which match
@ceo='McNealy' and see if they match the @worksfor property.
So maybe I would want something like this? I've annotated it with my
comments which
+DescendantSelfAxisQuery(+ChildAxisQuery(+ChildAxisQuery(_:PARENT:,
{}testroot), {}people), // returns all the child nodes of //people
// the subquery of DescendantSelfAxisQuery which return a bitset which
is subsection of the //people query. Unlike the
// DerefQuery it won't return the children, it'll return the parents
+ReverseDerefQuery(
+_:PROPERTIES_SET:1:worksfor // the sub query which
contain the UUIDs which we can match
_:PROPERTIES:1:ceo[McNealy _:PROPERTIES:1:ceo[1:McNealy, //
the query which will return the nodes to intersect with the sub query
null) // No name test - we'll match any node with the
@worksfor property
(I called it ReverseDerefQuery because it in essence is acting in reverse of
the DerefQuery. Returning parent UUIDs instead of children)
Thoughts?
Dan
--
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
On Fri, Apr 24, 2009 at 9:27 AM, Marcel Reutegger
marcel.reuteg...@gmx.netwrote:
Hi,
On Wed, Apr 22, 2009 at 21:57, Dan Diephouse
Wondering if I
have some freedom here. Otherwise it's going to end up a big ugly it
looks
like...
as an alternative we could try to add a new class, which leaves
RelationQueryNode untouched. but on the other hand that will introduce
a new method in QueryNodeVisitor. so we're back to square one.
I guess, no matter what we do there's always a chance that existing
code will break.
I was able to change this with just a small amount of breakage...
getRelativePath() now returns PathQueryNode instead of Path. I don't think
there is anyway around this... I doubt anyone is even using this API
oustide of jackrabbit, but I could of course be wrong.
Sorry this has taken so long to get on, but it's now top priority for me. I
was able to construct a QueryNode model alright, but now I'm pondering the
actual query itself. Hoping maybe you can confirm a few things.
When I do the query /people//jcr:deref(@worksfor, '*')[...@ceo = 'McNealy'] I
get a lucene query like:
+(_:PROPERTIES:1:ceo[McNealy
_:PROPERTIES:1:ceo[1:McNealy)
+DerefQuery(DescendantSelfAxisQuery(+ChildAxisQuery(+ChildAxisQuery(_:PARENT:,
{}testroot), {}people), _:PROPERTIES_SET:1:worksfor, 1), null, 1:worksfor)
Now switching this up to /people//*[jcr:deref(@worksfor,
'*')/@ceo='McNealy'] I'm wondering what the query should look like (is there
an API for testing these queries quickly/easily by just typing in a query
string?). I'm a bit stuck as I kind of need to do the opposite of the
DerefQuery - instead of returning the bitset of all the UUIDs in the
@worksfor property, I need the UUIDs of all the nodes which match
@ceo='McNealy' and see if they match the @worksfor property.
So maybe I would want something like this? I've annotated it with my
comments which
+DescendantSelfAxisQuery(+ChildAxisQuery(+ChildAxisQuery(_:PARENT:,
{}testroot), {}people), // returns all the child nodes of //people
// the subquery of DescendantSelfAxisQuery which return a bitset which
is subsection of the //people query. Unlike the
// DerefQuery it won't return the children, it'll return the parents
+ReverseDerefQuery(
+_:PROPERTIES_SET:1:worksfor // the sub query which
contain the UUIDs which we can match
_:PROPERTIES:1:ceo[McNealy _:PROPERTIES:1:ceo[1:McNealy, //
the query which will return the nodes to intersect with the sub query
null) // No name test - we'll match any node with the
@worksfor property
(I called it ReverseDerefQuery because it in essence is acting in reverse of
the DerefQuery. Returning parent UUIDs instead of children)
Thoughts?
Dan
--
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
Hi, On Wed, Apr 22, 2009 at 21:57, Dan Diephouse dan.diepho...@mulesource.com wrote: Does RelationQueryNode have to be API compatible with 1.5? it is a public class in spi-commons, which means it should be compatible with 1.5. I don't know how many projects out there depend on that class... Wondering if I have some freedom here. Otherwise it's going to end up a big ugly it looks like... as an alternative we could try to add a new class, which leaves RelationQueryNode untouched. but on the other hand that will introduce a new method in QueryNodeVisitor. so we're back to square one. I guess, no matter what we do there's always a chance that existing code will break. regards marcel On Wed, Apr 22, 2009 at 4:23 AM, Marcel Reutegger marcel.reuteg...@gmx.net wrote: Hi, On Mon, Apr 20, 2009 at 22:01, Dan Diephouse dan.diepho...@mulesource.com wrote: I'm looking into this now and have a question. In a non predicate query I see that Jackrabbit creates a DerefQueryNode and adds it to the PathQueryNode via addPathSetp. However, if one is working on a RelationQueryNode there is only the ability to add Path.Elements. Am I correct in understanding that RelationQueryNode may have to undergo some modifications here so it handle more than just foo/bar/@blah type paths? yes, I think that's a reasonable approach. Any suggestions on how this should look? Should RelationQueryNode maybe have a PathQueryNode whose results get evaluated against the operand/value instead of a series of Path.Elements? I'm not sure about all the details, but I guess that should work. I'd use keep the current methods and use a PathQueryNode internally for RelationQueryNode#relPath. then add new methods, i.e. - addPathStep(LocationStepQueryNode) - works similar to addPathElement() but allows you to also add a DerefQueryNode - getRelativePathNode() - works similar to getRelativePath() but returns the internal PathQueryNode just brain storming... might be missing something regards marcel (Does that even make sense? I still don't have a firm grasp of the query mechanisms) On Fri, Apr 17, 2009 at 5:51 PM, Dan Diephouse dan.diepho...@mulesource.com wrote: Yeah, it basically allows you to do joins of certain sorts when searching for items, which is *immensely* useful. I've got this coded up as two separate queries right now, but it's pretty slow and I can see how for some open queries it'd cause things to grind to a halt... Anyway, thanks for the feedback. I'll take a peek in the next couple days. Dan On Fri, Apr 17, 2009 at 3:36 AM, Marcel Reutegger marcel.reuteg...@gmx.net wrote: Hi, On Thu, Apr 16, 2009 at 21:40, Dan Diephouse dan.diepho...@mulesource.com wrote: I was contemplating implementing support for jcr:deref in xpath predicates a la https://issues.apache.org/jira/browse/JCR-977. There is a message from Mercel saying that the spec doesn't explicitly support this[1]. However it doesn't explicitly disallow it either... What is the feeling on Jackrabbit supporting it if I implement it? I think that would be a nice addition. I'd be very happy to review it and provide feedback. PS Still working on cleaning up my other patch for parent axis searching in axis predicates. cool. let us know if you need any help. regards marcel 1. http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06292.html -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
Hi, On Mon, Apr 20, 2009 at 22:01, Dan Diephouse dan.diepho...@mulesource.com wrote: I'm looking into this now and have a question. In a non predicate query I see that Jackrabbit creates a DerefQueryNode and adds it to the PathQueryNode via addPathSetp. However, if one is working on a RelationQueryNode there is only the ability to add Path.Elements. Am I correct in understanding that RelationQueryNode may have to undergo some modifications here so it handle more than just foo/bar/@blah type paths? yes, I think that's a reasonable approach. Any suggestions on how this should look? Should RelationQueryNode maybe have a PathQueryNode whose results get evaluated against the operand/value instead of a series of Path.Elements? I'm not sure about all the details, but I guess that should work. I'd use keep the current methods and use a PathQueryNode internally for RelationQueryNode#relPath. then add new methods, i.e. - addPathStep(LocationStepQueryNode) - works similar to addPathElement() but allows you to also add a DerefQueryNode - getRelativePathNode() - works similar to getRelativePath() but returns the internal PathQueryNode just brain storming... might be missing something regards marcel (Does that even make sense? I still don't have a firm grasp of the query mechanisms) On Fri, Apr 17, 2009 at 5:51 PM, Dan Diephouse dan.diepho...@mulesource.com wrote: Yeah, it basically allows you to do joins of certain sorts when searching for items, which is *immensely* useful. I've got this coded up as two separate queries right now, but it's pretty slow and I can see how for some open queries it'd cause things to grind to a halt... Anyway, thanks for the feedback. I'll take a peek in the next couple days. Dan On Fri, Apr 17, 2009 at 3:36 AM, Marcel Reutegger marcel.reuteg...@gmx.net wrote: Hi, On Thu, Apr 16, 2009 at 21:40, Dan Diephouse dan.diepho...@mulesource.com wrote: I was contemplating implementing support for jcr:deref in xpath predicates a la https://issues.apache.org/jira/browse/JCR-977. There is a message from Mercel saying that the spec doesn't explicitly support this[1]. However it doesn't explicitly disallow it either... What is the feeling on Jackrabbit supporting it if I implement it? I think that would be a nice addition. I'd be very happy to review it and provide feedback. PS Still working on cleaning up my other patch for parent axis searching in axis predicates. cool. let us know if you need any help. regards marcel 1. http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06292.html -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
Does RelationQueryNode have to be API compatible with 1.5? Wondering if I have some freedom here. Otherwise it's going to end up a big ugly it looks like... On Wed, Apr 22, 2009 at 4:23 AM, Marcel Reutegger marcel.reuteg...@gmx.netwrote: Hi, On Mon, Apr 20, 2009 at 22:01, Dan Diephouse dan.diepho...@mulesource.com wrote: I'm looking into this now and have a question. In a non predicate query I see that Jackrabbit creates a DerefQueryNode and adds it to the PathQueryNode via addPathSetp. However, if one is working on a RelationQueryNode there is only the ability to add Path.Elements. Am I correct in understanding that RelationQueryNode may have to undergo some modifications here so it handle more than just foo/bar/@blah type paths? yes, I think that's a reasonable approach. Any suggestions on how this should look? Should RelationQueryNode maybe have a PathQueryNode whose results get evaluated against the operand/value instead of a series of Path.Elements? I'm not sure about all the details, but I guess that should work. I'd use keep the current methods and use a PathQueryNode internally for RelationQueryNode#relPath. then add new methods, i.e. - addPathStep(LocationStepQueryNode) - works similar to addPathElement() but allows you to also add a DerefQueryNode - getRelativePathNode() - works similar to getRelativePath() but returns the internal PathQueryNode just brain storming... might be missing something regards marcel (Does that even make sense? I still don't have a firm grasp of the query mechanisms) On Fri, Apr 17, 2009 at 5:51 PM, Dan Diephouse dan.diepho...@mulesource.com wrote: Yeah, it basically allows you to do joins of certain sorts when searching for items, which is *immensely* useful. I've got this coded up as two separate queries right now, but it's pretty slow and I can see how for some open queries it'd cause things to grind to a halt... Anyway, thanks for the feedback. I'll take a peek in the next couple days. Dan On Fri, Apr 17, 2009 at 3:36 AM, Marcel Reutegger marcel.reuteg...@gmx.net wrote: Hi, On Thu, Apr 16, 2009 at 21:40, Dan Diephouse dan.diepho...@mulesource.com wrote: I was contemplating implementing support for jcr:deref in xpath predicates a la https://issues.apache.org/jira/browse/JCR-977. There is a message from Mercel saying that the spec doesn't explicitly support this[1]. However it doesn't explicitly disallow it either... What is the feeling on Jackrabbit supporting it if I implement it? I think that would be a nice addition. I'd be very happy to review it and provide feedback. PS Still working on cleaning up my other patch for parent axis searching in axis predicates. cool. let us know if you need any help. regards marcel 1. http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06292.html -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
I'm looking into this now and have a question. In a non predicate query I see that Jackrabbit creates a DerefQueryNode and adds it to the PathQueryNode via addPathSetp. However, if one is working on a RelationQueryNode there is only the ability to add Path.Elements. Am I correct in understanding that RelationQueryNode may have to undergo some modifications here so it handle more than just foo/bar/@blah type paths? Any suggestions on how this should look? Should RelationQueryNode maybe have a PathQueryNode whose results get evaluated against the operand/value instead of a series of Path.Elements? (Does that even make sense? I still don't have a firm grasp of the query mechanisms) On Fri, Apr 17, 2009 at 5:51 PM, Dan Diephouse dan.diepho...@mulesource.com wrote: Yeah, it basically allows you to do joins of certain sorts when searching for items, which is *immensely* useful. I've got this coded up as two separate queries right now, but it's pretty slow and I can see how for some open queries it'd cause things to grind to a halt... Anyway, thanks for the feedback. I'll take a peek in the next couple days. Dan On Fri, Apr 17, 2009 at 3:36 AM, Marcel Reutegger marcel.reuteg...@gmx.net wrote: Hi, On Thu, Apr 16, 2009 at 21:40, Dan Diephouse dan.diepho...@mulesource.com wrote: I was contemplating implementing support for jcr:deref in xpath predicates a la https://issues.apache.org/jira/browse/JCR-977. There is a message from Mercel saying that the spec doesn't explicitly support this[1]. However it doesn't explicitly disallow it either... What is the feeling on Jackrabbit supporting it if I implement it? I think that would be a nice addition. I'd be very happy to review it and provide feedback. PS Still working on cleaning up my other patch for parent axis searching in axis predicates. cool. let us know if you need any help. regards marcel 1. http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06292.html -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
Hi, On Thu, Apr 16, 2009 at 21:40, Dan Diephouse dan.diepho...@mulesource.com wrote: I was contemplating implementing support for jcr:deref in xpath predicates a la https://issues.apache.org/jira/browse/JCR-977. There is a message from Mercel saying that the spec doesn't explicitly support this[1]. However it doesn't explicitly disallow it either... What is the feeling on Jackrabbit supporting it if I implement it? I think that would be a nice addition. I'd be very happy to review it and provide feedback. PS Still working on cleaning up my other patch for parent axis searching in axis predicates. cool. let us know if you need any help. regards marcel 1. http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06292.html -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref in predicate
Yeah, it basically allows you to do joins of certain sorts when searching for items, which is *immensely* useful. I've got this coded up as two separate queries right now, but it's pretty slow and I can see how for some open queries it'd cause things to grind to a halt... Anyway, thanks for the feedback. I'll take a peek in the next couple days. Dan On Fri, Apr 17, 2009 at 3:36 AM, Marcel Reutegger marcel.reuteg...@gmx.netwrote: Hi, On Thu, Apr 16, 2009 at 21:40, Dan Diephouse dan.diepho...@mulesource.com wrote: I was contemplating implementing support for jcr:deref in xpath predicates a la https://issues.apache.org/jira/browse/JCR-977. There is a message from Mercel saying that the spec doesn't explicitly support this[1]. However it doesn't explicitly disallow it either... What is the feeling on Jackrabbit supporting it if I implement it? I think that would be a nice addition. I'd be very happy to review it and provide feedback. PS Still working on cleaning up my other patch for parent axis searching in axis predicates. cool. let us know if you need any help. regards marcel 1. http://www.mail-archive.com/dev@jackrabbit.apache.org/msg06292.html -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog -- Dan Diephouse http://mulesource.com | http://netzooid.com/blog
Re: jcr:deref() in predicate
Frédéric Esnault wrote: Thanks for the answer, but my question was : is there another way only using XPath? I should have been clearer, sorry. no, there is not. jcr:deref() can only be used to dereference a property along the path. e.g. foo/bar/jcr:deref(@myRef, '*')/bla regards marcel
Re: jcr:deref() in predicate
Frédéric Esnault wrote: Is it forbidden to put a jcr:deref in a predicate, knowing that we can use child nodes and properties? jackrabbit does not support the jcr:deref function in a predicate. please file a jira issue if you wish to see this enhancement in jackrabbit. regards marcel
RE: jcr:deref() in predicate
Thansk I will because if we don't have, how can we do this query. I want all contracts having as an internal contractor the company Lycos. Knowing that contractors are references in the contract type. I did /jcr:root/lgw:root/lgw:contracts/element(*, lgw:contractType)[jcr:deref(@lgw:internalContractor, 'lgw:contractorType')/@lgw:companyName = 'Lycos'] Is there antoher way to make this query? Frédéric Esnault - Ingénieur RD Legisway 60 boulevard de la mission Marchand 92400 Courbevoie La Défense -Message d'origine- De : Marcel Reutegger [mailto:[EMAIL PROTECTED] Envoyé : vendredi 22 juin 2007 11:25 À : dev@jackrabbit.apache.org Objet : Re: jcr:deref() in predicate Frédéric Esnault wrote: Is it forbidden to put a jcr:deref in a predicate, knowing that we can use child nodes and properties? jackrabbit does not support the jcr:deref function in a predicate. please file a jira issue if you wish to see this enhancement in jackrabbit. regards marcel
Re: jcr:deref() in predicate
Frédéric Esnault wrote:
Thansk I will because if we don't have, how can we do this query.
I want all contracts having as an internal contractor the company Lycos.
Knowing that contractors are references in the contract type.
I did /jcr:root/lgw:root/lgw:contracts/element(*,
lgw:contractType)[jcr:deref(@lgw:internalContractor,
'lgw:contractorType')/@lgw:companyName = 'Lycos']
Is there antoher way to make this query?
yes, there is. only search for the company node:
lgw:root//element(*, lgw:company)[EMAIL PROTECTED]:companyName = 'Lycos']
then use the API to get the references to the lycos company node:
Node lycosCompany = ...;
for (PropertyIterator it = lycosCompany.getReferences(); it.hasNext(); ) {
Property p = it.nextProperty();
if (p.getName().equals(lgw:internalContractor)) {
Node contractType = p.getParent();
// do something with this node
}
}
or even better, if there were no same name siblings you could directly address
the lycos company by path:
Node rootNode = ...;
rootNode.getNode(lgw:root/companies/Lycos);
that way you don't even have to execute a query.
in contrast to databases you don't necessarily have to use joins to get to your
content along references. the JCR API provides methods to do that much quicker
than a query.
regards
marcel
RE: jcr:deref() in predicate
Thanks for the answer, but my question was : is there another way only using
XPath? I should have been clearer, sorry.
Frédéric Esnault
-Message d'origine-
De : Marcel Reutegger [mailto:[EMAIL PROTECTED]
Envoyé : vendredi 22 juin 2007 12:28
À : dev@jackrabbit.apache.org
Objet : Re: jcr:deref() in predicate
Frédéric Esnault wrote:
Thansk I will because if we don't have, how can we do this query.
I want all contracts having as an internal contractor the company Lycos.
Knowing that contractors are references in the contract type.
I did /jcr:root/lgw:root/lgw:contracts/element(*,
lgw:contractType)[jcr:deref(@lgw:internalContractor,
'lgw:contractorType')/@lgw:companyName = 'Lycos']
Is there antoher way to make this query?
yes, there is. only search for the company node:
lgw:root//element(*, lgw:company)[EMAIL PROTECTED]:companyName = 'Lycos']
then use the API to get the references to the lycos company node:
Node lycosCompany = ...;
for (PropertyIterator it = lycosCompany.getReferences(); it.hasNext(); ) {
Property p = it.nextProperty();
if (p.getName().equals(lgw:internalContractor)) {
Node contractType = p.getParent();
// do something with this node
}
}
or even better, if there were no same name siblings you could directly address
the lycos company by path:
Node rootNode = ...;
rootNode.getNode(lgw:root/companies/Lycos);
that way you don't even have to execute a query.
in contrast to databases you don't necessarily have to use joins to get to your
content along references. the JCR API provides methods to do that much quicker
than a query.
regards
marcel
