jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: jcr:deref in predicate
Date Mon, 04 May 2009 09:47:59 GMT
On Fri, Apr 24, 2009 at 9:27 AM, Marcel Reutegger
<marcel.reutegger@gmx.net>wrote:

> 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

Mime
View raw message