Bug with issue 1558 - "Allow search to continue when sort field is missing from type mapping"


(Bryan Green) #1

Fails with ReduceSearchPhaseException[Failed to execute phase [fetch],
[reduce] ]; nested:

url: kk,system,library/statustype/_search
query: {"from":0,"size":999,"sort":{"order_no":
{"order":"asc","ignore_unmapped":true}}}

The "statustype" item type only exists in the system and library
indexes but not in the kk index.

The query executes against the kk index and either the system or
library index BUT when all three are together the search fails.

The title field is defined in the statustype item mapping and exists
in all instances.

Removing the sort of the query dsl causes the search to success.

If I remove the "ignore_unmapped" part of the sort then I receive
errors from the kk index but the search hits still come back for the
other indexes...

Preferably, the "ignore_unmapped" feature should allow all data to be
returned but provide a cascaded sort feature whereby ignoring certain
sort keys but still continuing with the next sort field (if
available.)

What else can I provide?

Thanks,
Bryan


(Shay Banon) #2

I see, the feature was added assuming the field is missing on all shards,
not on some of them. Open a different issue for that one, its trickier
though.

On Fri, Dec 30, 2011 at 5:24 AM, Bryan Green bryogreen@gmail.com wrote:

Fails with ReduceSearchPhaseException[Failed to execute phase [fetch],
[reduce] ]; nested:

url: kk,system,library/statustype/_search
query: {"from":0,"size":999,"sort":{"order_no":
{"order":"asc","ignore_unmapped":true}}}

The "statustype" item type only exists in the system and library
indexes but not in the kk index.

The query executes against the kk index and either the system or
library index BUT when all three are together the search fails.

The title field is defined in the statustype item mapping and exists
in all instances.

Removing the sort of the query dsl causes the search to success.

If I remove the "ignore_unmapped" part of the sort then I receive
errors from the kk index but the search hits still come back for the
other indexes...

Preferably, the "ignore_unmapped" feature should allow all data to be
returned but provide a cascaded sort feature whereby ignoring certain
sort keys but still continuing with the next sort field (if
available.)

What else can I provide?

Thanks,
Bryan

https://github.com/elasticsearch/elasticsearch/issues/1558


(Bryan Green) #3

Done...

Thank you.

On Dec 30, 5:24 am, Shay Banon kim...@gmail.com wrote:

I see, the feature was added assuming the field is missing on all shards,
not on some of them. Open a different issue for that one, its trickier
though.

On Fri, Dec 30, 2011 at 5:24 AM, Bryan Green bryogr...@gmail.com wrote:

Fails with ReduceSearchPhaseException[Failed to execute phase [fetch],
[reduce] ]; nested:

url: kk,system,library/statustype/_search
query: {"from":0,"size":999,"sort":{"order_no":
{"order":"asc","ignore_unmapped":true}}}

The "statustype" item type only exists in the system and library
indexes but not in the kk index.

The query executes against the kk index and either the system or
library index BUT when all three are together the search fails.

The title field is defined in the statustype item mapping and exists
in all instances.

Removing the sort of the query dsl causes the search to success.

If I remove the "ignore_unmapped" part of the sort then I receive
errors from the kk index but the search hits still come back for the
other indexes...

Preferably, the "ignore_unmapped" feature should allow all data to be
returned but provide a cascaded sort feature whereby ignoring certain
sort keys but still continuing with the next sort field (if
available.)

What else can I provide?

Thanks,
Bryan

https://github.com/elasticsearch/elasticsearch/issues/1558


(system) #4