Quantcast

XPath statement in eXist xquery - some advice please

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

XPath statement in eXist xquery - some advice please

badbetty
Hello again

I admit this is not so much a 'problem', or that it is purely eXist related. Still I would appreciate some comments to help me understand a) what it actually means and b) is it the most efficient xpath, especially regarding how xquery in eXist handles xpath selections?

Consider:

//order[./customer[ft:query(.,"searchtext")]]


To me it means,  get all orders where an order has  a child node 'customer'  of one found from the full text search  ....  perhaps  ?

The requirement in principle I guess, is to  pick out all parent nodes where a parent node has a child node belonging to a set returned from a full text search.

The above xpath appears to 'work' as such!

I realise there may be xquery scripts to 'do this better', but I am interested in a xpath statement in this case.


Thank you for any insight.

Chris
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XPath statement in eXist xquery - some advice please

Wolfgang Meier-2

> Consider:
>
> //order[./customer[ft:query(.,"searchtext")]]
>
> To me it means,  get all orders where an order has  a child node 'customer'
> of one found from the full text search  ....  perhaps  ?

The statement looks perfectly fine and should be efficient. From an xpath perspective, the ft:query function works like any other function (e.g. a standard contains), though internally eXist tries to optimize the entire statement. Instead of scanning all customer nodes and checking each for matching text content, eXist will do a single index lookup on customer/"searchtext" and map the result on the context order elements.

Technically, ft:query implements the Optimizable interface and is thus subject to query rewriting. eXist will thus try to evaluate the full text lookup up front, assuming that it will limit the node set to be processed.

If you find that the expression needs further optimization, a frequently applied trick is to do the customer lookup first and then use a reverse axis step to get at the corresponding order parents. This can save a lot of time, but I would only use it if there's really a bottleneck:

//customer[ft:query(., "searchtext") ] /parent::order

As always, you can use the query profiling panel in the admin webapp to see how indexes are used. The line calling the ft:query should show up as being in processed in" full " optimization mode.

I'm not sure if this answers your questions. If not please feel free to ask again.

Wolfgang


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Exist-open mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/exist-open
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: XPath statement in eXist xquery - some advice please

badbetty
Thank you Wolfgang -   it does explain some more and its always beneficial to have someone cast another set of eyes over matters to see if things can be improved etc.

All the best.
Chris
Loading...