On 2014-10-07, 4:04 PM, Dan Kennedy wrote:
On 10/08/2014 01:52 AM, Sohail Somani wrote:
Figured it out: match terms should be "l0l* h4x*" NOT "*l0l* *h4x*",
though it did work as expected with the older version. I'd suggest
keeping the old behaviour unless there is a performance-based reason
not to.
On 2014-10-07, 2:49 PM, Sohail Somani wrote:
SELECT COUNT(*) FROM t_fts WHERE t_fts MATCH '*l0l* *h4x*';
COMMIT;
BEGIN TRANSACTION;
INSERT INTO t(key,value0,value1) VALUES('$key','l0l','h4x');
COMMIT;
SELECT '--- 2 ---';
SELECT COUNT(*) FROM t_fts WHERE t_fts MATCH '*l0l* *h4x*';
Unfortunately, this was a break with backwards compatibility in response
to this issue:
https://www.mail-archive.com/sqlite-users@sqlite.org/msg83345.html
Before:
http://www.sqlite.org/src/info/e21bf7a2ade6373e
(version 3.8.6), it was up to the specific tokenizer being used whether
or not the special characters *, ", ( and ) were available to the query
parser. After that commit, they are stripped out first. So with the new
version, your query is now equivalent to "MATCH '101* h4x*'".
This should only affect FTS tables that use custom tokenizers (not the
default simple or porter tokenizers).
Got it, thanks for the explanation. Just to make sure that I understand
you correctly, is the clause MATCH '*l0l* *h4x*' getting translated to
MATCH 'l0l* h4x*'?
Sohail
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
