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/ba...@foo=bar]/chi...@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.reuteg...@gmx.net>wrote:
> Hi,
>
> On Mon, Feb 9, 2009 at 8:17 PM, Dan Diephouse
> <dan.diepho...@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
