sorting does not work when querying an alias #7343
Comments
|
the ticket about 1.3.2 is #7341 |
|
same failure is observed when querying multiple indexes instead of alias, i.e GET myindex_7,users_idx3/mytype/_search |
|
OK, looking at this issue and #7341, it looks like you have fields with the same name in different types in the same index. When you try to load these field values into fielddata, it chooses one of the field mappings (whichever one it finds first) and loads in that format. This is not new - it has been like this since the beginning. Fields with the same name should be mapped in the same way. We're planning on enforcing this in the future. See #4081 |
|
why does it work when searching through single index? |
|
It just depends on which field it happens to see first. |
|
thanks, got it |
|
i made sure all types in all indexes from that alias use the same type for that field but the sorting is still wrong when querying through alias, how can that be ? |
|
even cleared the cache for all indexes |
|
|
@OlegYch Apologies - I was wrong here, didn't read carefully enough, and was confused by the ClassCastException, which is usually related to the problem I described before. This does indeed look like a bug. Do you have the stack trace emitted when merging? Also, could you provide: thanks |
|
@clintongormley there doesn't seem to be any exceptions caused by query |
|
I'm not sure the bug is related to aliases. The sort values look wrong in both cases (even when querying a single index), see: {
"_index": "myindex_7",
"_type": "mytype",
"_id": "582313_1408387971.543879-0",
"_score": null,
"_source": {
"data": {
"distance": 871.749,
"end_date": 1408395600,
"calories": 0,
"motion_type": "stationary",
"start_date": 1408387971.543879,
"number_of_steps": 1167,
"duration": 7628.456121563911,
"order_date": 1408395600,
"id": "1408387971.543879-0"
},
"user_id": 582313
},
"sort": [
6.958361125e-315
]
}The value in So in spite of the fact that the field is mapped as a double in the mappings, it looks like it has been indexed as a long. I will try to dig more... |
|
The only explanation I can find is that the same field has been dynamically mapped as a long on some shards and as a double on other shards (before mappings propagation replicated the mappings to all nodes). |
|
i explicitly put the mapping for that type before putting any data in it, so i doubt that is the case |
|
This should have been resolved by the changes in #8870 in 2.0. Closing |
using 1.3.1 and 1.3.2 the ordering of results differs when searching on alias vs searching on the index with actual data from that alias (only one index in the alias has any data in the type)
returns
as opposed to correct sorting of data when querying single index
nevermind the broken aggregations and "sort" field values, this started to happen only after upgrade to 1.3.2
The text was updated successfully, but these errors were encountered: