Error response for multi query request including fuzzy search

[Nick-S-2018]

Bug Description:

curl localhost:9308/cli -d "CREATE TABLE test(f text) min_infix_len='2' ''

curl localhost:9308/cli -d "SELECT f FROM test WHERE MATCH('a') OPTION fuzzy=1;show meta;"
ERROR: P01: syntax error, unexpected ';' near ';show meta;SHOW META'

It looks that Fuzzy plugin generates the incorrect query when processing such request:

SELECT f FROM test WHERE MATCH('(a^50)') option idf='plain,tfidf_normalized', ;show meta;SHOW META

Manticore Search Version:

Manticore 7.4.7 2619d58d9@25031205 dev

Operating System Version:

Ubuntu 22.04

Have you tried the latest development version?

Yes

Internal Checklist:

^{To be completed by the assignee. Check off tasks that have been completed or are not applicable.}

• Implementation completed
• Tests developed
• Documentation updated
• Documentation reviewed
• Changelog updated

[Nick-S-2018]

Relates to manticoresoftware/manticoresearch-javascript#23

[donhardman]

I have started to fix it on the Buddy side but encountered other issues. Due to the architecture originally made in Buddy, I think this is not the way to go.

In Buddy, the response has always been mostly for a single query, and the idea originally was that the daemon would parse and send multiqueries separately.

So for SQL, it works fine when you send 'select * ..; show meta,' while if you send the same to the /sql endpoint that should mimic the original MySQL protocol, the daemon processes it in a different way and is unable to split it, sending to Buddy only what it needs to send.

Also, regarding show meta, we already added this support to Buddy, so any select proxied to the Buddy daemon gets show meta back.

I believe the change on Buddy is kind of hard and requires deep refactoring, and the proper way is just to do the logic on the daemon side because it is already able and works as expected in the mysql> protocol, but it does not mimic the behavior in the HTTP endpoint for the same MySQL protocol. The behavior is not consistent.

Example

Case 1

mysql> SELECT title FROM test WHERE MATCH('cybersecurity') OPTION fuzzy=1, distance=1, preserve=1; show meta;
+---------------------------------------------------+
| title                                             |
+---------------------------------------------------+
| cybersecurity |
+---------------------------------------------------+
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| total          | 1     |
| total_found    | 1     |
| total_relation | eq    |
| time           | 0.005 |
+----------------+-------+
mysql>

The RAW communication request:

[BUDDY] [68257712b081a1.81555085] request data: {"type":"unknown sql request","error":{"message":"unknown option 'fuzzy'","body":null},"version":3,"user":"root","message":{"path_query":"","body":"SELECT title FROM test WHERE MATCH('cybersecurity') OPTION fuzzy=1, distance=1, preserve=1","http_method":""}}

Case 2

root@dev:/workdir/manticore# curl localhost:9308/sql?mode=raw -d "SELECT title FROM test WHERE MATCH('cybersecurity') OPTION fuzzy=1, distance=1, preserve=1; show meta;
"; echo

The RAW communication request:

[BUDDY] [682576dc079b69.76667425] request data: {"type":"unknown sql request","error":{"message":"unknown option 'fuzzy'","body":{"error":"unknown option 'fuzzy'"}},"version":3,"user":"","message":{"path_query":"/sql?mode=raw","body":"SELECT title FROM test WHERE MATCH('cybersecurity') OPTION fuzzy=1, distance=1, preserve=1; show meta;\n","http_method":""}}

What is not very clear here is why, while using the mysql> protocol, it works well, but mimicking an HTTP endpoint works differently.

[donhardman]

Logic implemented with buddy refactoring to support multiple responses

@Nick-S-2018 please review:

• Fix/multi query show meta #539
• Refactor to support multi response buddy-core#123

[github-actions]

Thanks for the update! However, the internal checklist is not yet complete. A Manticore team member will close this issue once everything is checked off. 🛠️