-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix match
query for integer fields
#1037
base: main
Are you sure you want to change the base?
Conversation
The `match` query is in most cases a full-text search, e.g.: ```json { "query": { "match": { "message": "this is a test" } } } ``` However, it can also be used to find an exact value against a integer field: ```json { "query": { "match": { "products_count": "5" } } } ``` In such case Quesma would generate an invalid SQL, trying to do an `ILIKE` against an `Int64` column: ``` Illegal type Int64 of argument of function ilike ``` Fix the issue by introducing an internal __quesma_match operator and a transformation which transforms it either to `ILIKE` or `=`. Fixes QuesmaOrg#1018
quesma/quesma/schema_transformer.go
Outdated
} | ||
switch field.Type.String() { | ||
case schema.QuesmaTypeInteger.Name, schema.QuesmaTypeLong.Name, schema.QuesmaTypeUnsignedLong.Name: | ||
return model.NewInfixExpr(lhs, "=", model.NewLiteral(rhs.Value.(string))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about other data types? data, float?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Elastic's documentation doesn't specify this behavior (and the code itself is convoluted), but empirically testing with Elastic:
- float: doesn't work (tried
AvgTicketPrice:123.12
filter) - boolean: works, therefore added it to switch
- date:
date_field:[DATE_VALUE]
doesn't work; you can click to filter by it in Kibana, but then it emits different filter thanmatch
- keyword:
keyword_field:[KEYWORD_VALUE]
emits a different filter thanmatch
I did not test other types. Therefore, I think it's OK for us to support only those types mentioned in switch
right now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
The
match
query is in most cases a full-text search, e.g.:However, it can also be used to find an exact value against a integer field:
In such case Quesma would generate an invalid SQL, trying to do an
ILIKE
against anInt64
column:Fix the issue by introducing an internal __quesma_match operator and a transformation which transforms it either to
ILIKE
or=
.Fixes #1018