.keyword query is not planned correctly.

[hsuanyi]

According to DQL.

field:query means token matching. This is implemented as substring in quesma. Mostly it is correct/acceptable for most use cases .
field.keyword:query means exact matching. This is also implemented as substring in quesma. This is not ideal given exact matching is quite doable in with sql.

See this example:

input
"query": { "bool": { "filter": [ { "bool": { "minimum_should_match": 1, "should": [ { "match": { "system.keyword": "XXX" } } ] } }, { "range": { "logging_time": { "format": "strict_date_optional_time", "gte": "2025-05-29T17:36:00.481Z", "lte": "2025-05-29T17:51:00.481Z" } } } ], "must": [], "must_not": [], "should": [] } },

output:
SELECT ... FROM ... WHERE ("system" ILIKE '%XXX%' AND ("time">= fromUnixTimestamp64Milli(1748536156236) AND "time"<= fromUnixTimestamp64Milli(1748537056236))) ORDER BY "time" DESC LIMIT 500

[hsuanyi]

A solution might be to to use schemaOverride https://docs.quesma.com/config-primer?

Do i have to add both keyword and text if a field might be used for token matching and exact matching? seems quite inconvenient

[hsuanyi]

Hi team. This is my proposal:

we probably do not need schemaOverride https://docs.quesma.com/config-primer to determine if a field is text or keyword based.

Instead, at query time, we just make judgement based on user query. specifically, if it is field:XXX => ilike based matching; if it is field.keyword:XXX => exact matching.

I can make a pr. just want to make sure we are on the same page on this.

[pdelewski]

You are right, that's bug or gap in our transformation logic. I reproduced the same behavior.

SELECT "age", "name", "timestamp"
FROM default.cat
WHERE ("name" ILIKE '%Friday%' AND (NULL>='2025-05-29T17:36:00.481Z' AND NULL<=
  '2025-05-30T17:51:00.481Z'))
LIMIT 10

It seems that the problem exists when field is multi field

However it does not exists when field is keyword

Will be happy to take your PR.