An issue with parameterized N1QL query

I there, I noticed an issue with parametrized query using Java Client 2.3.7 which is by default included by Spring Data Couchabse.

Consider bucker activity which has a property data containing an object.
Over the data property is created an index

CREATE INDEX `data-index` ON `activity` (DISTINCT ARRAY t FOR t WITHIN data END);

if I run following query via Administration panel

`SELECT count(*) as size FROM activity a WHERE  ANY t WITHIN `data` SATISFIES t LIKE 'searchTerm' END`

everything works fine Execution: 7.45ms. In the buckets is 1.8M documents.

If the query is executed using Java Client

JsonObject params = JsonObject.create().put("query", 'searchTerm');
String statement = "SELECT count(*) as size FROM activity a WHERE  ANY t WITHIN `data` SATISFIES t LIKE $query END";
N1qlQuery countN1ql =  N1qlQuery.parameterized(statement, params);
N1qlQueryResult result = template.queryN1QL(countN1ql);

It is timing out. I think there is an issue with parametrized query, because if is in the statement directly used the searchTerm like this:

String statement = "SELECT count(*) as size FROM activity a WHERE ANY t WITHIN `data` SATISFIES t LIKE 'searchTerm' END";

it works fine. But I don’t want directly put the search term in the query due to injection.

NOTE: The other parametrized statements works fine, just SATISFIES cause somehow does not like it.

Thanks for help

Which version of the server? There was a similar discussion recently that was resolved by moving to server 4.6.

If it’s 4.6 already or you’re on an older version that you can’t upgrade from, can you get debug/trace level logs that demonstrate the issue?

I am using the latest Community Version 4.5. I can not upgrade to DP 4.6 until it will be Current release. Do you have an idea when will be released also Community 4.6?

Which logs should I particularly check, just query?

I don’t know when 4.6 CE would be released. @WillGardella can probably advise.

On logs, my suggestion there was rather if you can’t try with the latest, can you get trace logs at the client or a packet capture of port 8093 to share the back and forth between the client and server? What that’ll do is help me with problem determination and filing the right issue on your behalf.

For instance, with tcpdump, something like this should capture what’s needed to inspect:

shell> tcpdump -C 500 -W 10 -w /path/to/save/file/(filename).pcap -s 0 port 8093