Od MongoDB v2.6 nie ma typu dziesiętnego ze stałymi miejscami. Dane muszą być zapisane w polu innego typu, a aplikacja musi za każdym razem wykonywać tłumaczenie.
Potencjalnie biblioteki pośredniczące mogą wykonać to tłumaczenie zamiast twojej aplikacji. Myślę, że net.liftweb.record nie.
Jeśli typ podwójny wystarczyłby dla danego pola, dla uproszczenia zalecam zmianę na ten. Ale zakładając, że używasz BigDecimal z dobrych powodów, istnieją dobrze znane obejścia. Są to:
(1) Przechowuj jako ciąg . Możesz mieć dowolną precyzję. Ale sortowanie lub wyszukiwanie dokładnych dopasowań wartości będzie działać tylko wtedy, gdy za każdym razem dopełnisz lewą stronę zerami do stałej długości. Nawet wtedy liczby dodatnie i ujemne to dwa różne zakresy sortowania. Negatywy muszą być posortowane odwrotnie, aby uzyskać prawidłowe sortowanie numeryczne. Przykład kolejności, w której MongoDB naturalnie zwróci te liczby ciągów uzupełnione zerami:
"-0000054321.9876"
"-0000100322"
"0000054321.9876"
"0000100322"
Uważam, że typ BigDecimal ma konstruktor z wartości ciągu, więc może to być najłatwiejsze do zaimplementowania w funkcji tłumaczenia aplikacji.
(2) Przechowuj jako przesunięty długi (Int64) . Sortowanie działa, zużywa się mniej miejsca na dysku, nie ma problemów z ujemnym vs. pozytywny. Wymaga przesunięcia wartości w górę o ustaloną wielokrotność, co czyni nieco nieczytelnym przy bezpośrednim spojrzeniu na bazę danych. Dokładność musi być taka sama dla wszystkich wartości w całym zbiorze – OK dla finansowych przypadków użycia; nie jest OK w niektórych naukowych przypadkach użycia.
(3) Przechowuj jako parę liczb , po jednej dla każdej strony przecinka dziesiętnego. Sortowanie wymaga dodatkowej pracy. W przypadku korzystania z liczb Int32 precyzja zostanie ograniczona do 9 cyfr po obu stronach przecinka dziesiętnego. Patrzenie na dwie kolumny w bazie danych zamiast jednej to oczywiście trochę więcej pracy.
Dla przykładu kodu Scala znalazłem sterownik Reactive dla projektu MongoDB udokumentowany trzy obejścia serializacji dla BigDecimal . Pierwszy używa podwójnego; dwa ostatnie przyjmują jeszcze inne podejście – tworzą cały dokument podrzędny dla wartości BigDecimal. Podejrzewam, że próba zapytania o wartości zawarte w poddokumentach byłaby trudna.
Inny prawdziwy przypadek z bloga zespołu deweloperów Ebay (Morphia/Java)
PS być może MongoDB doda w przyszłości typ dziesiętny. Istnieje otwarta prośba o funkcję, którą możesz obejrzeć/zagłosować – https://jira. mongodb.org/browse/SERVER-1393
