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.

Sign up for GitHub

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

Jump to bottom

timestamp term match broken in 0.18.5 #1543

Closed
dobe opened this issue Dec 15, 2011 · 8 comments
Closed

timestamp term match broken in 0.18.5 #1543

dobe opened this issue Dec 15, 2011 · 8 comments
Labels
>bug v0.18.6 v0.19.0.RC1

Comments

@dobe
Copy link

dobe commented Dec 15, 2011

using a boolean query with a timestamp in a term, returns non-matching items.

the example below returns all items with searched domain and ANY "ts" value in 0.18.5. in 0.17.6 the "ts" field must match. we already tried it with integer and string fields instead of the timestamp field which works, so it seems this is timestamp related?

we also tried using a filtered query and filtering by "ts" which does not work either.

e.g:

{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "domains": "adidas.com"
          }
        },
        {
          "term": {
            "ts": 1316995200000
          }
        }
      ]
    }
  },
  "fields": "*"
}

we also tried using the "ts" as the only requirement. in this case entries from the matching day are returned but the time does not need to match.

{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "ts": 1316995200000
          }
        }
      ]
    }
  },
  "fields": "*"
}

the searched timestamp is Mo Sep 26 00:00:00 UTC 2011, but results appear with timestamps like this ts: 2011-09-26T04:19:38.000Z
@kimchy
Copy link
Member

kimchy commented Dec 15, 2011

Can you gist a full curl recreation that shows this, with creation of index (with custom mappings if you have it), and then search that shows the problem.

@jukart
Copy link
Contributor

jukart commented Dec 15, 2011

The recreation: https://gist.github.com/1481503

@dobe
Copy link
Author

dobe commented Dec 15, 2011

for backward compat we enabled this:

index :
mapping:
date:
parse_upper_inclusive: false

but does not work without this config too

@kimchy
Copy link
Member

kimchy commented Dec 15, 2011

Yea, its a regression due to the new "parse_upper_inclusive" setting. You can disable it for now and I will push a fix to master and 0.18.6.

@dobe
Copy link
Author

dobe commented Dec 15, 2011

thanks for your immediate replies.

i can't disable it in our cluster, because an application relies on the old behavior. when do you plan to release 0.18.6?

thx

@dobe
Copy link
Author

dobe commented Dec 15, 2011

fyi: i tested it again if it works without setting parse_upper_inclusive ... it does not fix the issue

@kimchy
Copy link
Member

kimchy commented Dec 15, 2011

The old behavior is preserved when setting the parse_upper_inclusive to false, if you don't set it, it will use the new behavior which has the bug with term matching.

@kimchy kimchy closed this as completed in f745b80 Dec 15, 2011
@dobe
Copy link
Author

dobe commented Dec 15, 2011

you are right, the setting fixes the issue!
thanks for the very fast responses and fix!

mute pushed a commit to mute/elasticsearch that referenced this issue Jul 29, 2015
@kimchy
timestamp term match broken in 0.18.5, closes elastic#1543.
f4614f0
jev001 pushed a commit to jev001/elasticsearch that referenced this issue Dec 28, 2022
@kimchy
timestamp term match broken in 0.18.5, closes elastic#1543.
166e4b0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
>bug v0.18.6 v0.19.0.RC1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@kimchy @dobe @jukart