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

default_field param of QUERY() won't be deployed to Query String Query #32602

Closed
kosho opened this issue Aug 3, 2018 · 3 comments
Closed

default_field param of QUERY() won't be deployed to Query String Query #32602

kosho opened this issue Aug 3, 2018 · 3 comments

Comments

@kosho
Copy link

kosho commented Aug 3, 2018

Elasticsearch version (bin/elasticsearch --version): 6.3.2

Plugins installed: []

JVM version (java -version): 1.8.0_181

OS version (uname -a if on a Unix-like system): Darwin Kernel Version 17.7.0

Description of the problem including expected versus actual behavior:

As I am supplying default_field=<field> parameter in the QUERY operand in the WHERE clause, it won't be deployed into query_string query.

Steps to reproduce:

  1. Create a new index with a single document as below:
PUT test/test/1
{
  "tag_line": "You know for search",
  "product": "Elasticsearch"
}
  1. Throw the following query to _xpack/sql/translate endpoint.
POST _xpack/sql/translate
{
  "query": "SELECT * FROM test WHERE QUERY('search', 'default_field=tag_line', 'default_operator=and')"
}
  1. Check if default_field is not shown in the response while default_operator=and is reflected.
{
  "size": 1000,
  "query": {
    "query_string": {
      "query": "search",
      "fields": [],
      "type": "best_fields",
      "default_operator": "and",
      "max_determinized_states": 10000,
      "enable_position_increments": true,
      "fuzziness": "AUTO",
      "fuzzy_prefix_length": 0,
      "fuzzy_max_expansions": 50,
      "phrase_slop": 0,
      "escape": false,
      "auto_generate_synonyms_phrase_query": true,
      "fuzzy_transpositions": true,
      "boost": 1
    }
  },
  "_source": {
    "includes": [
      "product",
      "tag_line"
    ],
    "excludes": []
  },
  "sort": [
    {
      "_doc": {
        "order": "asc"
      }
    }
  ]
}

Provide logs (if relevant):

@kosho kosho added the :Analytics/SQL SQL querying label Aug 3, 2018
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-search-aggs

@colings86
Copy link
Contributor

@astefan Could you take a look at this?

matriv added a commit to matriv/elasticsearch that referenced this issue Sep 18, 2018
Previously multiple comma separated lists of options where not
recognized correctly which resulted in only the last of them
to be taked into account, e.g.:

For the following query:
  SELECT * FROM test WHERE QUERY('search', 'default_field=foo', 'default_operator=and')"
only the `default_operator=and` was finally passed to the ES query.

Fixes: elastic#32602
@matriv
Copy link
Contributor

matriv commented Sep 18, 2018

@kosho Meanwhile as a workaround you could do the following:
SELECT * FROM test WHERE QUERY('search', 'default_field=tag_line;default_operator=and')

@matriv matriv assigned matriv and unassigned astefan Sep 18, 2018
matriv pushed a commit that referenced this issue Sep 19, 2018
Previously multiple comma separated lists of options where not
recognized correctly which resulted in only the last of them
to be taked into account, e.g.:

For the following query:
  SELECT * FROM test WHERE QUERY('search', 'default_field=foo', 'default_operator=and')"
only the `default_operator=and` was finally passed to the ES query.

Fixes: #32602
matriv pushed a commit that referenced this issue Sep 19, 2018
Previously multiple comma separated lists of options where not
recognized correctly which resulted in only the last of them
to be taked into account, e.g.:

For the following query:
  SELECT * FROM test WHERE QUERY('search', 'default_field=foo', 'default_operator=and')"
only the `default_operator=and` was finally passed to the ES query.

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

No branches or pull requests

5 participants