Блог

Я использую Гумз 7.6. При выполнении поисковых запросов в Solr дает неправильную версию поля документа, а все другие поля являются правильными.

В панели мониторинга Solr запрос выдает следующий результат:

 {
        "id":"518fce46-3617-4380-aaf6-8f6d36e08e6a",
        "type":"tag",
        "count":1,
        "_version_":1626999925241806848
}
  

В то время как функция поиска solr-узла выдает:

 {
         "id": "518fce46-3617-4380-aaf6-8f6d36e08e6a",
         "type": "tag",
         "count": 1,
         "_version_": 1626999925241806800
}
  

Первоначальное предположение заключается в том, что модуль solr-node возвращает значение как double (вместо строки), а точность double недостаточно хороша для точного представления значения 1626999925241806848 .

Мы можем подтвердить это непосредственно в консоли нашего браузера:

 -> 1626999925241806848
<- 1626999925241806800
  

т. е. если мы введем числовое значение 1626999925241806848 , оно будет представлено ближайшим числом с плавающей запятой, и это 1626999925241806800 .

Вероятно, solr-node должен возвращать эти значения в виде строки, когда они превышают представимое значение для целых чисел.

Обновление: solr-node подробно описывает это на своей обзорной странице:

Используйте json-bigint для корректной обработки чисел, слишком больших для Javascript, таких как значения полей *l и _version. По умолчанию библиотека json-bigint не используется, потому что разница в производительности по сравнению с собственной библиотекой JSON слишком важна для «большого» фрагмента JSON (https://github.com/lbdremy/solr-node-client/issues/114#issuecomment-54165595), но вы хотите включить его, если используете функцию оптимистичного совпадения, доступную в Solr 4.x, наряду с функциями получения в реальном времени и атомарных обновлений, поскольку они используют поле version. Чтобы включить это, сделайте var client = solr.createClient({ bigint : true}) или непосредственно на экземпляре клиента client.options.bigint = true .