Hi,
I can try. But what you tell me and what I saw with the unit test function I guess the GUI does something that can't be observed when using scripts.
Unfortunately I get new problems with 9.3.2 Beta:
declare function local:maptest() as map(xs:string, xs:string) { let $xml := <_ test="test"/> return map{xs:string($xml/@test): xs:string('test')} };
local:maptest()
stopped working.
[XPTY0004] Cannot convert map(*) to map(xs:string, xs:string): map { "test": "test" }.
And I get more new type conversion related errors that were not reported before. This is temporary I hope?
Best regards
Omar
Am 06.02.2020 um 14:11 schrieb Christian Grün:
Looks we are getting closer. I have attached a little command script; do you think you can adapt it such that it captures the potential bug?
On Thu, Feb 6, 2020 at 1:51 PM Omar Siam Omar.Siam@oeaw.ac.at wrote:
The following XQuery run in the GUI (pulled from github and built a few minutes ago from source)
ft:tokens('testdata'), ft:search('testdata', 'r.ḥ', map {'wildcards': true()})/.., '----------' ,collection('testdata')//*[text() contains text 'r.ḥ' using wildcards]
yields
<entry count="4">rwḥ</entry>
with collection('testdata')
<_> <gram xmlns="http://www.tei-c.org/ns/1.0" type="root" xml:lang="ar-aeb-x-vicav">rwḥ</gram> <gram xmlns="http://www.tei-c.org/ns/1.0" type="root" xml:lang="ar-aeb-x-vicav">rwḥ</gram> <gram xmlns="http://www.tei-c.org/ns/1.0" type="root" xml:lang="ar-aeb-x-vicav">rwḥ</gram> <gram xmlns="http://www.tei-c.org/ns/1.0" type="root" xml:lang="ar-aeb-x-tunis-vicav">rwḥ</gram> </_>
But the gh1800() test changed like this:
final String text = "999 aa 1111 rwḥ"; [...] query("ft:search('" + NAME + "', 'r.ḥ', " + options + ")", text);
works.
Am 06.02.2020 um 13:45 schrieb Christian Grün:
I just tried to use the gh1800 test to replicate my problem and it does not show there. It fails using the GUI.
I need your help: What does not show there? What fails, what happens?
Am 06.02.2020 um 13:35 schrieb Christian Grün:
Hi Omar,
Yes, that seems to solve the problem partly. Using wildcards now yields the same result as no wildcards.
Glad to hear.
But if there is a complex unicode character in the search string, "." for one character looses its meaning. … Would you like a PR for the test gh1800 using complex unicode characters?
A little test case would be helpful indeed. It seems to be a different issue:
• The first expression is evaluated without the full-text expression. The reason is that the full-text index algorithms are limited to basic regular expressions; not all of them can be answered by an index (and 'r{1,1}' is currently not detected as being identical to `r.`). If I remember correctly, the index will not be accessed either if a pattern starts with `.*` (this pattern would lead to a full index scan).
• The second expression is rewritten for index access. I tried to build a little command script (test.bxs), but it doesn’t seem to reflect the case you encountered:
set ftindex true create db test <xml>rwḥ</xml> xquery /*[text() contains text 'r.{1,1}ḥ' using wildcards] xquery /*[text() contains text 'r.ḥ' using wildcards] close
Could you extend this example script a little, such that it demonstrates what goes wrong?
Thanks in advance, Christian