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

Error while using wildcard in multifield query_string query #3054

Closed
eliaslevy opened this issue May 17, 2013 · 2 comments
Closed

Error while using wildcard in multifield query_string query #3054

eliaslevy opened this issue May 17, 2013 · 2 comments

Comments

@eliaslevy
Copy link

I've indexed some data with a field named "observed" that is an object with two other fields named "filename" and "pathname". These fields are analyzed and have multiple values.

The following query executed without problems:

"query_string" : { 
  "fields" : ["observed.filename", "observed.pathname"], 
  "query" : "Autorun", 
  "use_dis_max" : true 
}

but when I change it to the following it fails:

"query_string" : {
  "fields" : ["observed.*"],
  "query" : "Autorun",
  "use_dis_max" : true
}

with the error:

"SearchPhaseExecutionException[Failed to execute phase [query], total failure; shardFailures {[jHW46VKNS_G6Cnrdzko_WA][file_analysis][0]: SearchParseException[[file_analysis][0]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\t"query": {\t "query_string" : {\t "fields" : ["observed."],\t "query" : "Autorun",\t "use_dis_max" : true\t }\t}}]]]; nested: NumberFormatException[For input string: "Autorun"]; }{[jHW46VKNS_G6Cnrdzko_WA][file_analysis][1]: SearchParseException[[file_analysis][1]: from[-1],size[-1]: Parse Failure [Failed to parse source [{\t"query": {\t "query_string" : {\t "fields" : ["observed."],\t "query" : "Autorun",\t "use_dis_max" : true\t }\t}}]]]; nested: NumberFormatException[For input string: "Autorun"]; }]

Why is that? The docs indicate it should work.

Also odd is that the following works:

"query_string" : {
  "fields" : ["observed.f*"],
  "query" : "Autorun",
  "use_dis_max" : true
}

but this fails:

"query_string" : {
  "fields" : ["observed.p*"],
  "query" : "Autorun",
  "use_dis_max" : true
}

I am Running 0.90.0. The mapping for the fields looks like:

"observed" : {
  "type": "object",
  "properties" : {
    "pathname"  : { "type": "string", "analyzer": "path"              },
    "filename"  : {
      "type": "multi_field",
      "fields": {
        "filename": { "type": "string", "analyzer": "path"              },
        "whole"   : { "type": "string", "analyzer": "lowercase_keyword" }
      }
    }
  }
}

There are some other fields in there as well.

@mattweber
Copy link
Contributor

This is not a wildcard issue, it is due to attempting to search a field with the wrong format. You must have a numeric field that begins with a p inside of the observed object. When using your wildcard, this field get's included in the searchable fields and thus throws and error when you attempt to search it using a query string. Set the lenient parameter to true to ignore these types of errors as documented here: http://www.elasticsearch.org/guide/reference/query-dsl/query-string-query/

@eliaslevy
Copy link
Author

Doh. Makes sense. Thanks for pointing it out Matt. Closing.

martijnvg pushed a commit to martijnvg/elasticsearch that referenced this issue Jan 31, 2018
This change removes the InternalClient and the InternalSecurityClient. These are replaced with
usage of the ThreadContext and a transient value, `action.origin`, to indicate which component the
request came from. The security code has been updated to look for this value and ensure the
request is executed as the proper user. This work comes from elastic#2808 where @s1monw suggested
that we do this.

While working on this, I came across index template registries and rather than updating them to use
the new method, I replaced the ML one with the template upgrade framework so that we could
remove this template registry. The watcher template registry is still needed as the template must be
updated for rolling upgrades to work (see elastic#2950).
martijnvg pushed a commit that referenced this issue Feb 5, 2018
This change removes the InternalClient and the InternalSecurityClient. These are replaced with
usage of the ThreadContext and a transient value, `action.origin`, to indicate which component the
request came from. The security code has been updated to look for this value and ensure the
request is executed as the proper user. This work comes from #2808 where @s1monw suggested
that we do this.

While working on this, I came across index template registries and rather than updating them to use
the new method, I replaced the ML one with the template upgrade framework so that we could
remove this template registry. The watcher template registry is still needed as the template must be
updated for rolling upgrades to work (see #2950).
martijnvg added a commit that referenced this issue Feb 5, 2018
* es/6.x: (155 commits)
  Make persistent tasks work. Made persistent tasks executors pluggable.
  Removed ClientHelper dependency from PersistentTasksService.
  Added AllocatedPersistentTask#waitForPersistentTaskStatus(...) that delegates to PersistentTasksService#waitForPersistentTaskStatus(...)
  Add adding ability to associate an ID with tasks.
  Remove InternalClient and InternalSecurityClient (#3054)
  Make the persistent task status available to PersistentTasksExecutor.nodeOperation(...) method
  Refactor/to x content fragments2 (#2329)
  Make AllocatedPersistentTask members volatile (#2297)
  Moves more classes over to ToXContentObject/Fragment (#2283)
  Adapt to upstream changes made to AbstractStreamableXContentTestCase (#2117)
  Move tribe to a module (#2088)
  Persistent Tasks: remove unused isCurrentStatus method (#2076)
  Call initialising constructor of BaseTasksRequest (#1771)
  Always Accumulate Transport Exceptions (#1619)
  Pass down the provided timeout.
  Fix static / version based BWC tests (#1456)
  Don't call ClusterService.state() in a ClusterStateUpdateTask
  Separate publishing from applying cluster states
  Persistent tasks: require allocation id on task completion (#1107)
  Fixes compile errors in Eclipse due to generics
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants