-
Notifications
You must be signed in to change notification settings - Fork 186
VerificationException: When using multiple indices, the mappings must be identical. #46
Comments
Here are some references for issues/fixes on the xpack version of elasticsearch: |
Thanks for bringing this up. This was a design choice to support common use case of log analytics where the indexes have similar prefixes and underlying mappings are same. We have noted this enhancement and will be out with a fix soon. |
Hi , Im also facing the same issue , any idea for rollout a fix for the same. |
… test, add a new one
… check; delete useless test case
Hi @horacimacias,
Correct. We will still be enforcing the mappings for fields mentioned as part of
This is already the case. |
Perhaps I'm missing something but I'm getting different results on a 0.9.0 environment. Here's what I did to try with clean values. These indexes didn't exist before. Create two documents, one on each index, both having a common field and one having an extra field:
Selecting field common to all documents:
I get the error mentioned:
Selecting both fields on "myindex*":
gives me the same error (it does not give me empty value for the field2 on the myindex1 doument). Selecting both fields on myindex1 (the document does not have a field2 value):
gives me the same output as searching for "field" on myindex1:
So, the request is allowed but the missing fields are completely ignored. |
Case-1: Selecting field common to all documents. Case-2 : Selecting both fields on "myindex*". Case-3: Selecting both fields on myindex1, gives me the same output as searching for "field" on myindex1. In the below example, hello field does not exist even in the mappings. nickname exists in mappings, but not in document with id: 2.
To get results for missing fields in the documents , jdbc format can be used here. Here the result has as many columns as requested.
For both Case-1 and Case-2 we are coming up with a fix, we don't have an ETA on this, as it requires major changes. |
thanks! |
…dices query with compatible mappings. Add new test cases and data. Delete useless test case
…dices query with compatible mappings. Add new test cases and data. Delete useless test case
…h compatible mappings. Give user detailed error message on incompatible mappings. Add new IT test cases and data. Delete useless test case
I've just tested with opendistro 1.0.0 and I'm still seeing the same behaviour for cases 1 and 2. This is what I did, in case my expectations are incorrect:
Case-1: Selecting field common to all documents/indices. Case-2 : Selecting both fields on "myindex*". are these supposed to work on opendistro 1.0.0? am I doing anything wrong? |
I just double checked the fix is supposed to be in version 1.1.0+. Please try it out and let us know if you still see the issue. Thanks! |
…es query with compatible mappings. Give … ( opendistro-for-elasticsearch#84)
I'm trying to run SQL queries on an index alias (e.g. select field from myindex-*) and my indexes are daily (so I have myindex-2019-04-01, etc.).
For some of the indexes, additional fields have been added and dynamic field mapping has updated the mapping, resulting on myindex-2019-04-01 having less fields compared to myindex-2019-04-02 for example.
When running SQL queries, elasticsearch is complaining with:
even though the SQL query is not using the fields that are different between the indexes.
Is there any way to relax the strictness of all mappings having to be identical?
if I run:
and the mapping for myfield is the same on all indexes matching myindex*, do we really want to enforce the whole mapping is identical? I'm not seeing the benefit of that.
even if some indexes do not contain myfield, wouldn't it be better to just return an empty value for such column instead of not allowing the request at all?
The text was updated successfully, but these errors were encountered: