Solr - научное обозначение двойного не может быть проанализировано - PullRequest
0 голосов
/ 06 июня 2018

Для тестирования я пытаюсь записать значения C. Double.MIN (-1.79769313486232E + 308) и Double.Max (1.79769313486232E + 308) в Solr TrieDoubleField с помощью библиотеки SolrNet.Оба двойных значения отправляются через XML на сервер Solr, который выводит следующие журналы:

2018-06-06 13: 27: 46.840 DEBUG (qtp33524623-14) [x: Test] oasupAllValuesOrNoneFieldMutatingUpdateProcessor field 'd_DoubleMin 'String value' -1.79769313486232E + 308 'не является изменяемым, поэтому никакие значения не будут видоизменены 2018-06-06 13: 27: 46.840 DEBUG (qtp33524623-14) [x: Test] oasupParseDoubleFieldUpdateProcessorFactory value' '1.6232693488не разбирается, поэтому не мутирует;непарсированные символы: 'E + 308' 2018-06-06 13: 27: 46.840 DEBUG (qtp33524623-14) [x: Test] oasupAllValuesOrNoneFieldMutatingUpdateProcessor поле 'd_DoubleMax' Строковое значение '1.79769313486232E + 308', значение mutable не будет, 308быть мутированным

Solrnet использует научную запись для передачи этих двойных значений, но Solr, похоже, не в состоянии разобрать его, вероятно.Когда я проверяю содержимое добавленного документа Solr, оба значения устанавливаются в '-infinity' и 'infinity' соответственно.

Однако, когда я записываю NaN, '-infinity' и 'infinity' в Solr, все значения сохраняются, как и ожидалось.

Я также проверил двойную спецификацию C # и Solr, которая, кажется, не совпадает:

Это ошибка SolrNet или я что-то упустил?

1 Ответ

0 голосов
/ 07 июня 2018

Чтобы решить эту проблему, я реализовал собственный DoubleFieldSerializer (производный от SolrNets AbstractFieldSerializer).Мой DoubleFieldSerializer вместо этого вызывает obj.ToString ("R") в функции Parse.Я сделал то же самое для значений с плавающей точкой.

Недостаток моего решения заключается в том, что мне нужно переопределить DefaultFieldSerializer, чтобы иметь возможность регистрировать мои FieldSerializer (аналогично Dans solution ).

Я также опубликовал эту проблему на Github.Так что, возможно, это будет исправлено в будущем: https://github.com/SolrNet/SolrNet/issues/422

...