Skip to content
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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

avelanarius
Copy link
Member

The match query is in most cases a full-text search, e.g.:

{
  "query": {
    "match": {
      "message": "this is a test"
    }
  }
}

However, it can also be used to find an exact value against a integer field:

{
  "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 #1018

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
}
switch field.Type.String() {
case schema.QuesmaTypeInteger.Name, schema.QuesmaTypeLong.Name, schema.QuesmaTypeUnsignedLong.Name:
return model.NewInfixExpr(lhs, "=", model.NewLiteral(rhs.Value.(string)))
Copy link
Member

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?

Copy link
Member Author

@avelanarius avelanarius Nov 26, 2024

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 than match
  • keyword: keyword_field:[KEYWORD_VALUE] emits a different filter than match

I did not test other types. Therefore, I think it's OK for us to support only those types mentioned in switch right now.

@avelanarius avelanarius marked this pull request as ready for review November 26, 2024 10:01
@avelanarius avelanarius requested a review from a team as a code owner November 26, 2024 10:01
Copy link
Member

@nablaone nablaone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Illegal type Int64 of argument of function ilike
2 participants