First question post-ElasticSearch training! Using v.90.3. I know this is
one of those long specific questions that rarely gets answers, but it is
worth a shot.
What I'm seeing is some sort of bad caching of the terms filter using
bitsets. It's even that one node might return the correct result while the
other doesn't. I did a fresh index this morning and immediately started
getting errors from the application due to data disagreement. I even
deleted the type, recreated, and reimported the data. We use an alias to
manage index switches. Unfortunately, I cannot reproduce this with a full
gist. A simple example doesn't seem to have the issue and it seems to be
intermittent.
mappings
"id": {
"type": "integer",
"analyzer": "keyword",
"store":"yes"
}
data
{
"id":343
,"name":"blue pegs"
,"hierarchy":{"id":343}
}
{
"id":353
,"name":"half sized blue pegs"
,"hierarchy":{"id":343^353}
}
{
"id":501
,"name":"orange pegs"
,"hierarchy":{"id":501}
}
query terms filter like so:
{"filter": {
"terms": {
"id": [
343
,501
]
}
}
}
What I will get back for terms [343,501]
343,353 <- wrong!
If I set cache:false or "execution":"bool" I will get the correct response
of [343,501]
What I get back for terms: [343]
343 <- correct
What I get back for terms: [501]
501 <- correct
What I get back for terms: [353]
353 <- correct
What I get back for terms: [353,343]
353,343 <-correct!
There is something very funny going on here.
--
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elasticsearch+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/3904b3c7-142d-48f3-a5df-41ef1d0aace3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.