Doh! Thanks for pointing out the obvious. (And sorry for the two email messages to the list)

Another question, and hopefully, this won't be my 3rd strike. :-) 

I think I'm getting close to getting this implemented. I set up a DB with /root/base[@foo=bar]/child[@foo=bar]. I have some basic searches working. My query "//child/..[@foo] gets constructed into:

+PROPERTIES_SET:1:foo +ParentAxisQuery(+DescendantSelfAxisQuery(+ChildAxisQuery(_:PARENT:, {}testroot), name() = {}child, 1), null)

And, voila, it works! Attribute queries are a bit trickier. Let's say I wanted to do "//child[../@foo]". I think I would have to end up doing something like this:

+(+PROPERTIES_SET:1:foo +ParentAxisQuery(+DescendantSelfAxisQuery(+ChildAxisQuery(_:PARENT:, {}testroot), name() = {}child, 1), null))
  +DescendantSelfAxisQuery(+ChildAxisQuery(_:PARENT:, {}testroot), name() = {}child, 1)

Why is the DescendantSelfAxisQuery there twice? Well, you could have multiple parent axis queries (e.g. "//child[../@foo and ../@bar]") in which case I don't see any way around it. Do others see a cleaner way to implement that?

If that is the only way to structure the query, I'm struggling a little bit with the best way to implement that in the LuceneQueryBuilder. It'd be nice if there was a way to clone Querys, but I don't see a way to do that. So I could try rebuilding the query from the QueryNode, but then I'd have to put in some magic to prevent it from getting stuck in an infinite loop. That is, I'd have to make it build a query for only //child and not //child[../@foo].

Cheers,
Dan


On Mon, Feb 9, 2009 at 1:59 PM, Marcel Reutegger <marcel.reutegger@gmx.net> wrote:
Hi,

On Mon, Feb 9, 2009 at 8:17 PM, Dan Diephouse
<dan.diephouse@mulesource.com> wrote:
> This is probably a rather obvious question, but I'm trying to understand the
> queries that Jackrabbit is putting together and figured I'd fire off an
> email to see if anyone could help me out quick. My xpath query is
> "//child[foo/@foo = 'bar']" and the lucene query is:
> +(+(_:PROPERTIES:1:foo[bar _:PROPERTIES:1:foo[1:bar) +name() = {}foo)
> +DescendantSelfAxisQuery(+ChildAxisQuery(_:PARENT:, {}testroot), name() =
> {}child, 1)
> Why are there two "_:PROPERTIES:1:foo[bar" ?

those two are not identical, the second one has a '1:' before the 'bar'.

because jackrabbit cannot tell whether 'bar' is a literal of type
STRING or NAME by just parsing XPath, it simply searches for both
occurrences. the 1 you are seeing in the second term is the index
internal prefix for the default namespace uri.

regards
 marcel



--
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog