Change default generated Elasticsearch query to something that works with > 6

[tryantwit]

Is your feature request related to a problem? Please describe.
The Query Sandbox section for Elasticsearch generates with the default query

{
  "query": {
    "match": {
      "_all": "#$query##"
    }
  }
}

Trying to use against Elasticsearch 6 doesn't work without changing the query due to the removal of the _all field.

Describe the solution you'd like
It would be nice if the default generated query worked off something like "multi_match" instead if the desire is to search across multiple fields. Or potentially specify a target ES version to start with a default query that works.

Additional context
Point of confusion when introducing the tool to new team members to play around with. When they generate a new relevancy case and it doesn't work immediately they get confused. The intention is usually to change the query anyway but seeming like it can't query the index at all from the get go causes some headache.

[epugh]

Could you provide an example query with the multi_match, and we could see how that goes? I’ll look too if we should, at this point, assume you are on ES 6 and change the field to something else.

…

On Aug 7, 2019, at 4:44 PM, Tim Ryan ***@***.***> wrote: Is your feature request related to a problem? Please describe. The Query Sandbox section for Elasticsearch generates with the default query { "query": { "match": { "_all": "#$query##" } } } Trying to use against Elasticsearch 6 doesn't work without changing the query due to the removal of the _all field. Describe the solution you'd like It would be nice if the default generated query worked off something like "multi_match" instead if the desire is to search across multiple fields. Or potentially specify a target ES version to start with a default query that works. Additional context Point of confusion when introducing the tool to new team members to play around with. When they generate a new relevancy case and it doesn't work immediately they get confused. The intention is usually to change the query anyway but seeming like it can't query the index at all from the get go causes some headache. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAAFO67H2Y66IGDIEVQRJ5TQDMX4XA5CNFSM4IKEDWP2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HD7WQTQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAFO6YF7AC7547Z6JS46PDQDMX4XANCNFSM4IKEDWPQ>.

_______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.

[tryantwit]

Sure thing. Ended up putting this in and leaving fields out to just search across whatever.

{
  "query": {
    "multi_match": {
       "query": "#$query##"
     }
   }
}

[epugh]

Quick update, I'm working on being able to deploy both ES 5 and ES 6, so it's easier to test different versions..

[epugh]

Okay, I've redeployed our demo ES servers, and the same TMDB dataset is available under ES 5, 6, and 7!

• http://quepid-elasticsearch.dev.o19s.com:9200/tmdb/_search is ES6
• http://quepid-elasticsearch.dev.o19s.com:9205/tmdb/_search is ES5
• http://quepid-elasticsearch.dev.o19s.com:9206/tmdb/_search is ES6
• http://quepid-elasticsearch.dev.o19s.com:9207/tmdb/_search is ES7

[epugh]

@tryantwit I tried your change, and it works great on ES 6 and 7, but doesnt' work on ES 5... Ideally our starter query works on ES 5,6, and 7.. We could add some sort of special messaging or something, but that is a pain. Any ideas on a single query?

[epugh]

Is 5 at this point legacy? Maybe the default path through Quepid is to assume either ES 6 or 7?

[tryantwit]

Well that's great. I have no idea if 5 is legacy enough to just assume ES 6 or 7. I would assume new comers to search would end up using ES 6 or 7. I'll do some looking/thinking about a single query.

Outside of messaging we could hit the ES server to pull the version and auto default to a query but that's also a pain.

[epugh]

Yeah…. I wonder if a poll on the #quepid channel is a good idea and see… The more “let me ping the ES to configure Quepid” the more likely something goes wrong. Maybe we just ask you to specify your version.. I.e “We support these searach engines and version, pick yours…” Ugh. Poll may be good right next step.

…

On Aug 8, 2019, at 3:43 PM, Tim Ryan ***@***.***> wrote: Well that's great. I have no idea if 5 is legacy enough to just assume ES 6 or 7. I would assume new comers to search would end up using ES 6 or 7. I'll do some looking/thinking about a single query. Outside of messaging we could hit the ES server to pull the version and auto default to a query but that's also a pain. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AAAFO66TKJ3QSLQ7ORBBFKLQDRZMJA5CNFSM4IKEDWP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34WHII#issuecomment-519660449>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAFO65BRPS3XSP4Q65VH4TQDRZMJANCNFSM4IKEDWPQ>.

_______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.

[tryantwit]

Quick glance, a query_string search might work.

{
  "query": {
   "query_string": {
      "query": "#$query##"
   }
  }
}

[epugh]

We may have a winner!

…

On Aug 8, 2019, at 3:46 PM, Tim Ryan ***@***.***> wrote: query_string

_______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.

[epugh]

Here is a Twitter poll I am running: https://twitter.com/dep4b/status/1159553085250969601

[tryantwit]

Awesome! Glad that query works across the versions. Keeps it simple. Cast my vote in the poll as well, though at this point the results might just be of personal interest.

[epugh]

okay, this has been fixed in #3 however not deployed yet. WOrking on deploying...

[epugh]

Finally have the related PR merged into master.. Will redeploy app.quepid.com on Monday.

[epugh]

and deployed.