You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If job-1 has been created using a partitoning field host then this is added to the mappings of the shared results index.
If a subsequent job-2 is created using host.keyword then the job creation will fail, because the results index already contains this field (named as host).
Having these extra mapping fields makes it much better for searching results as the end-user can use familiar syntax host: server1.
To workaround this, we currently recommend using a dedicated index for job-2. This will keep their results separate allowing host and host.keyword to exist in different indices.
As the results index always uses keywords as a data type, an alternative would be to check if host.keyword is a multi-field (and not a nested field) and then truncate the field name to plain host. This may lead to downstream issues in the UI where is has to plot source data and would need to know if it should use host or host.keyword.
The text was updated successfully, but these errors were encountered:
The problem description is copied from #29954 (comment)
If job-1 has been created using a partitoning field host then this is added to the mappings of the shared results index.
If a subsequent job-2 is created using host.keyword then the job creation will fail, because the results index already contains this field (named as host).
Having these extra mapping fields makes it much better for searching results as the end-user can use familiar syntax host: server1.
To workaround this, we currently recommend using a dedicated index for job-2. This will keep their results separate allowing host and host.keyword to exist in different indices.
As the results index always uses keywords as a data type, an alternative would be to check if host.keyword is a multi-field (and not a nested field) and then truncate the field name to plain host. This may lead to downstream issues in the UI where is has to plot source data and would need to know if it should use host or host.keyword.
The text was updated successfully, but these errors were encountered: