От MongoDB v2.6 няма десетичен тип с фиксирани знаци. Данните трябва да се записват в поле от различен тип и приложението трябва да извършва превод всеки път.
Потенциално междинните библиотеки биха могли да направят този превод вместо вашето приложение. Предполагам, че net.liftweb.record не го прави.
Ако двоен тип би бил достатъчен за въпросното(ите) поле(я), препоръчвам да го промените за по-лесно. Но ако приемем, че използвате BigDecimal по основателни причини, има добре известни решения. Това са:
(1) Запазете го като низ . Можете да имате произволна точност. Но сортирането или запитването за точни съвпадения на стойност ще работи само ако всеки път допълвате лявата страна с нули до фиксирана дължина. Дори тогава положителните и отрицателните числа са два различни диапазона по отношение на сортирането. Негативите трябва да бъдат сортирани в обратен ред, за да има правилно числово сортиране. Пример за реда MongoDB естествено ще върне тези номера на низове с нула:
"-0000054321.9876"
"-0000100322"
"0000054321.9876"
"0000100322"
Вярвам, че типът BigDecimal има конструктор от стойност на низ, така че това може да е най-лесният за внедряване във функцията за превод на вашето приложение.
(2) Запазете го като изместен дълъг (Int64) . Сортирането работи, използва се по-малко дисково пространство, няма проблеми с отрицателни v.s. положителен. Изисква изместване на стойностите нагоре с фиксирано кратно, което прави малко нечетливо, когато гледате директно базата данни. Точността трябва да бъде фиксирана, за да бъде еднаква за всички стойности в цялата колекция - ОК за случаи на финансова употреба; не е добре за някои случаи на научна употреба.
(3) Съхраняване като чифт числа , по един за двете страни на десетичната запетая. Сортирането изисква допълнителна малко работа. Ако използвате числа Int32, точността ще бъде ограничена до 9 цифри от двете страни на десетичната запетая. Разглеждането на две колони в базата данни вместо една е малко повече работа, разбира се.
За пример за код на Scala открих, че драйверът Reactive за проекта MongoDB е документирал три заобиколни решения за сериализация за BigDecimal . Първият използва двойно; последните две използват още един подход - създават цял поддокумент за BigDecimal стойност. Подозирам, че опитът за заявка за стойности, обвити в поддокументи, би бил труден.
Друго случай от реалния живот от блог на екип за разработчици на Ebay (Morphia/Java)
P.S. може би MongoDB ще добави десетичен тип в бъдеще. Има отворена заявка за функция за него, която можете да гледате/гласувате за - https://jira. mongodb.org/browse/SERVER-1393
