Vanaf MongoDB v2.6 is er geen decimaaltype met vaste plaatsen. De gegevens moeten worden opgeslagen in een veld van een ander type en de toepassing moet elke keer een vertaling uitvoeren.
Mogelijk zouden de tussenliggende bibliotheken deze vertaling kunnen doen in plaats van uw toepassing. Ik denk dat net.liftweb.record dat niet doet.
Als een dubbel type zou volstaan voor het/de betreffende veld(en), raad ik aan om daar voor de eenvoud naar over te stappen. Maar ervan uitgaande dat u BigDecimal om goede redenen gebruikt, zijn er bekende oplossingen. Dit zijn:
(1) Bewaar het als een string . U kunt elke willekeurige precisie hebben. Maar sorteren of zoeken naar exacte waardeovereenkomsten werkt alleen als u de linkerkant elke keer met nullen tot een vaste lengte opvult. Zelfs dan zijn positieve en negatieve getallen qua sortering twee verschillende reeksen. De negatieven moeten in omgekeerde volgorde worden gesorteerd om een correcte numerieke sortering te hebben. Een voorbeeld van de volgorde MongoDB zal natuurlijk deze nul-opgevulde tekenreeksnummers retourneren:
"-0000054321.9876"
"-0000100322"
"0000054321.9876"
"0000100322"
Ik geloof dat het BigDecimal-type een constructor van een tekenreekswaarde heeft, dus dit is misschien het gemakkelijkst te implementeren in de vertaalfunctie van uw toepassing.
(2) Bewaar het als een verschoven long (Int64) . Sorteren werkt, er wordt minder schijfruimte gebruikt, geen problemen met negatieve v.s. positief. Vereist het opschuiven van de waarden met een vast veelvoud, wat een beetje onleesbaar maakt als je rechtstreeks naar de database kijkt. De precisie moet worden vastgesteld om hetzelfde te zijn voor alle waarden in de hele verzameling - OK voor financiële gebruiksgevallen; niet OK voor sommige wetenschappelijke gebruiksgevallen.
(3) Opslaan als een paar cijfers , één voor elke kant van de komma. Sorteren vereist wat extra werk. Als u Int32-nummers gebruikt, is de precisie beperkt tot 9 cijfers aan weerszijden van het decimaalteken. Twee kolommen in de db bekijken in plaats van één is natuurlijk wat meer werk.
Voor een Scala-codevoorbeeld vond ik dat het Reactive-stuurprogramma voor het MongoDB-project drie tijdelijke oplossingen voor serialisatie voor BigDecimal . De eerste gebruikt dubbel; de laatste twee nemen nog een andere benadering:maak een heel subdocument voor BigDecimal-waarde. Het zou lastig zijn om waarden op te vragen die in subdocumenten zijn verpakt, vermoed ik.
Nog een echte casus van een blog van het Ebay-ontwikkelteam (Morphia/Java)
PS misschien zal MongoDB in de toekomst een decimaal type toevoegen. Er is een open functieverzoek voor dat je kunt bekijken/upvoten - https://jira. mongodb.org/browse/SERVER-1393