Match_none was introduced in later versions, but there has to be a way to mimic the behavior in 1.7.5? Any leads would be appreciated.
Basically, I want to return a query which will match no documents, but my global aggregations would still run.
Found out I can use MustNot in combination with MatchAll (must not match all)
Related
I'm upgrading my codebase's ElasticSearch from 5.6 to 7.x due to some features I'd like to explore.
I'm currently using GoLang & "github.com/olivere/elastic/v5" specifically.
However, auto_generate_phrase_query has been depreciated, and AutoGeneratePhraseQueries no longer works on v7 ("github.com/olivere/elastic/v7").
I've read to use explicit quoted queries, what is the equivalent to that in olivere? is there no setting i can set to true/false in ES when making requests to achieve this? Must i explicitly wrap my queries in quotation marks? Surely there must be a proper way to do this...
I found this: https://www.elastic.co/guide/en/elasticsearch/reference/6.8/query-dsl-query-string-query.html
which states use [type=phrase] instead
In Olivere, i can set this via: Type("phrase"); is this a sufficient alternative?
The closest thing was actually using Phrase Queries. For anyone in the future coming back to find an answer.
Is it possible to highlight the matching parts in the results of a completion suggester query?
(Caveat: I am new to Elasticsearch and the answer given relies solely on the two links I posted below. However, these are official Elasticsearch / Lucene sources and they are pretty clear about it)
As of today (2016-06-28), it does not seem to be possible.
This feature would not be implemented in Elasticsearch but in the underlying Lucene. However, it seems to be a complex issue that is not going to be resolved anytime soon.
See:
https://github.com/elastic/elasticsearch/issues/8089
https://issues.apache.org/jira/browse/LUCENE-4518
Is it possible to enable wild card queries by default using query_string?
I'm having to manually append * to each of the terms. I had a look at the documentation but couldn't find anything.
No there is no way to enable it. You can enable/disable using wildcards "allow_leading_wildcard" the way how it works, that ES try to match tokens. So if you search for car it will match car until you search car* then it will match cars (sure it depends on analysis but further there is link for you to read).
I dont know case what you want to do but you should look to dealing with language. It should help also note that using leading wildcard could have performance issues that is why sometimes is better to disable it.
our system is running elasticsearch 0.19.9.
recentyly i'm going to add a new mapping on it. what i need is merge multiple whitespaces into a single whitespace.
i do some search ,and find pattern_replace is what i need, code are like
"space_filter":{
"type":"pattern_replace",
"pattern":"\\s+",
"replacement":"\\s"
}
but the bad news is "pattern_replace" is not introduced until 0.90.*. so is there possibily to backport this function into the version i'm using?
really i don't want to upgrade this system the newest version, guessing it's time consuming, as i'm also using es-head and bigdesk. the version match thing might kill me.
I have a Lucene index of document, all nearly identical (test 1, test 2, etc.) except that some have a higher boost than others. When using a default query (MatchAllDocsQuery OR .Parse(":") on the query parser) the documents come back in the order they went in every time. By adding a search term ("test" in this case), the document boost is apparent and the documents are sorted according to the boost. I can change the boost levels around and the new order is reflected in the results. All my code is pretty standard fair, I'm using a default Sort() is both cases.
I found that this same bug was reported and fixed in Lucene back in 2005-2006, and I checked my MatchAllDocsQuery.cs file (Lucene .NET 2.9.2) and it seems to have this change present, but the behavior is as described in the ticket above.
Any ideas what I might be doing wrong? Perhaps someone running the Java version has experienced this (or not)? Thanks.
Uh, don't I feel silly now. This is as-designed behavior. I guess. According to Lucene in Action, MatchAllDocsQuery uses a constant for the boost.