full text with search term in a variable gives no matches
The following query gives me no results: for $city as xs:string in ("Paris", "Cambridge", "London", "Oxford") return ( $city, count(/dictionary/letter/entry[.//p//text() contains text {$city}]), " " ) However, BaseX rewrites it to for $city as xs:string in ("Paris", "Cambridge", "London", "Oxford", ...) return ($city, fn:count(db:fulltext("with-sources", { $city })/ancestor::*:p/ancestor::*:entry), " ") If I remove the braces around $city in the argument to db:fulltext() I get the right answers (or at least plausible answers). So this looks like a bug in the rewriting engine. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Hi Liam,
The following query gives me no results:
could you pass me on a document for testing? Your query seemed to do the right thing for the following document: <dictionary><letter><entry><p>Paris</p></entry></letter></dictionary>
for $city as xs:string in ("Paris", "Cambridge", "London", "Oxford", ...) return ($city, fn:count(db:fulltext("with-sources", { $city })/ancestor::*:p/ancestor::*:entry), " ")
The optimized expression string does not always show the exact internal representation, so it may well be that something else happens when this query is evaluated. In the given case, there is no equivalent XQuery expression/function for the internal index rewriting, so the db:fulltext() function is shown instead. Thanks, Christian
On Sun, 2013-05-12 at 10:41 +0200, Christian Grün wrote:
Hi Liam,
The following query gives me no results:
I rebuilt the full text index and now get results. Yay! :-) To be sure, I re-indexed the document and rebuilt all the indexes. However, for $city in ("Paris", "Cambridge", "London", "Oxford", "boy") return ($city, count(/dictionary/letter/entry[.//text() contains text {$city}]), " ") gives me Paris 1 Cambridge 0 London 0 Oxford 0 boy 174 but for $city in ("Paris", "Cambridge", "London", "Oxford", "boy") return ($city, count(/dictionary/letter/entry[. contains text {$city}]), " ") gives me Paris 2485 Cambridge 1132 London 2444 Oxford 1863 boy 180 (changing .//text() to . in the ft expression). The higher figures are more likely to be correct. The actual document (50MBytes) is at http://words.fromoldbooks.org/xml/Chalmers-Biography/with-sources.xml Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Hi Liam, this is unusual; for the referenced document, Using ".//text()", I get.. Paris: 2485 Cambridge: 1136 London: 2444 Oxford: 1865 boy: 180 …and using ".", I get… Paris: 2484 Cambridge: 1130 London: 2442 Oxford: 1860 boy: 179 I get similar results for CHOP = true and false. Have you tried to completely recreate your database in order to see what happens? Christian ___________________________ On Mon, May 13, 2013 at 6:24 AM, Liam R E Quin <liam@w3.org> wrote:
On Sun, 2013-05-12 at 10:41 +0200, Christian Grün wrote:
Hi Liam,
The following query gives me no results:
I rebuilt the full text index and now get results. Yay! :-) To be sure, I re-indexed the document and rebuilt all the indexes.
However,
for $city in ("Paris", "Cambridge", "London", "Oxford", "boy") return ($city, count(/dictionary/letter/entry[.//text() contains text {$city}]), " ")
gives me Paris 1 Cambridge 0 London 0 Oxford 0 boy 174
but
for $city in ("Paris", "Cambridge", "London", "Oxford", "boy") return ($city, count(/dictionary/letter/entry[. contains text {$city}]), " ")
gives me Paris 2485 Cambridge 1132 London 2444 Oxford 1863 boy 180
(changing .//text() to . in the ft expression).
The higher figures are more likely to be correct.
The actual document (50MBytes) is at http://words.fromoldbooks.org/xml/Chalmers-Biography/with-sources.xml
Liam
-- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
participants (2)
-
Christian Grün -
Liam R E Quin