Ошибка в массовом запросе: [arg] не может быть изменен с типа [long] на [float]
У меня проблемы с конфигурацией пакета FOSElastica. Я использую сериализатор JMS и пытаюсь добавить объекты, поля которых буквально содержат массив json. Но когда я пытаюсь заполнить некоторые из них, это дает мне следующие ошибки:
Error in one or more bulk request actions:
index: /table_content/table_content/10 caused mapper [corrected_value_float.args.argument1] cannot be changed from type [long] to [float]
index: /table_content/table_content/11 caused mapper [difference_value_float.entry] cannot be changed from type [float] to [long]
В настоящее время мне трудно понять, как он определяет, какой тип аргумента находится в массиве json. Чтобы было ясно, я думаю, что JMS просто сериализует объект, как и любой другой, и связывает {"поле": "значение"} как json, и здесь "значение" в базе данных является фактическим массивом json, поэтому эластика индексирует его и вроде "угадать" тип значений массива.
Проблемный массив json для /table_content/table_content/10 (думаю, ему не нравится 100 в конце «argument1»):
{
"args": {
"argument1":[0.0002777777777777778,1.123888888888889,2.2475,3.371111111111111,4.494722222222222,5.618333333333334,6.741944444444444,7.865555555555555,8.988888888888889,10.112499999999999,11.23611111111111,12.359722222222222,13.483333333333333,14.606944444444444,15.730555555555556,16.854166666666668,17.977777777777778,19.10138888888889,20.224999999999998,21.34861111111111,22.47222222222222,23.59583333333333,24.71944444444444,25.842777777777776,26.96638888888889,28.09,29.21361111111111,30.33722222222222,31.460833333333333,32.58444444444444,33.70805555555556,34.83166666666667,35.95527777777778,37.07888888888889,38.2025,39.32611111111112,40.44972222222222,41.57333333333334,42.696666666666665,43.82027777777778,44.943888888888885,46.0675,47.191111111111105,48.31472222222222,49.43833333333333,50.56194444444444,51.68555555555555,52.80916666666666,53.93277777777777,55.05638888888888,56.18,57.30361111111111,58.426944444444445,59.550555555555555,60.674166666666665,61.797777777777775,62.921388888888885,64.045,65.16861111111112,66.29222222222222,67.41583333333334,68.53944444444444,69.66305555555556,70.78666666666666,71.91027777777778,73.03388888888888,74.1575,75.28083333333333,76.40444444444445,77.52805555555555,78.65166666666667,79.77527777777777,80.89888888888889,82.0225,83.14611111111111,84.26972222222223,85.39333333333335,86.51694444444445,87.64055555555557,88.76416666666667,89.88777777777779,91.01138888888889,92.13472222222222,93.25833333333334,94.38194444444444,95.50555555555556,96.62916666666666,97.75277777777778,98.87638888888888,100]
}
}
Проблемный массив json для /table_content/table_content/11:
{"args": {
"entry":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
}
}
Что касается второго проблемного массива, я даже не понимаю, почему он считает одно из чисел числом с плавающей запятой, если оно состоит только из 0.
Как я могу сказать ему, какой тип присваивать значениям массива json, даже если я использую сериализатор для остальных объектов? Где в пакете elastica он «угадывает», какой тип находится в этих массивах?
О, это имело бы смысл, поскольку я не могу найти ничего, чтобы указать это в коде FOSElastica. Таким образом, моим единственным решением было бы создать собственное сопоставление и не полагаться на сериализатор... Посмотрим, спасибо за внимание
Поскольку мой комментарий, кажется, решил вашу проблему, я предоставляю его как ответ, чтобы вы могли пометить его как принятое решение. Рад помочь, получайте удовольствие
Ну, это не решило мою проблему, я не могу сделать это с FOSElastica, и мне пришлось бы делать сопоставление вручную (а у меня около 50 таблиц с десятками полей для каждой, некоторые из которых связаны между собой). Но это ответило на вопрос о том, как ElasticSearch создает сопоставление, когда явно не определен тип, так что спасибо за это.
Ответы 2
Elasticsearch создаст сопоставление в зависимости от первого документа, который он проиндексирует, если вы его не предоставите. Попробуйте проверить _mapping вашего индекса. Вы можете указать сопоставление самостоятельно, чтобы избежать этого.
Итак, через какое-то время я нашел решение своих проблем: Динамические шаблоны и Шаблоны индексов
На самом деле у меня были проблемы с тем, что ElasticSearch не распознавал некоторые типы полей (например, дату или гео_точку), поэтому я принудительно использовал их для полей с конкретными именами с помощью шаблонов.
Если вам нужен пример моей конфигурации в FOSElastica (документ здесь):
fos_elastica:
serializer:
serializer: jms_serializer
clients:
default:
host: localhost
port: 9200
index_templates: # https://www.elastic.co/guide/en/elasticsearch/reference/6.8/indices-templates.html
base_template: # this is a custom name for the index template
client: default
template: "*" # this is where you define which indices will use this template
types:
_doc: # this is where you define which types will use this (_doc stands for every type/documents)
dynamic_templates: # https://www.elastic.co/guide/en/elasticsearch/reference/6.8/dynamic-templates.html
dynamic_date_template: # this is a custom name for the dynamic field template
match_pattern: regex
match: created|updated|tpq_date|taq_date
mapping:
type: date
dynamic_location_template:
match: location
mapping:
type: geo_point
Elasticsearch создаст сопоставление в зависимости от первого документа, который он проиндексирует, если вы его не предоставите. Попробуйте проверить
_mappingвашего индекса. Вы можете указать сопоставление самостоятельно, чтобы избежать этого.