Ab MongoDB v2.6 gibt es keinen Dezimaltyp mit festen Stellen. Die Daten müssen in einem Feld eines anderen Typs gespeichert werden und die Anwendung muss jedes Mal eine Übersetzung durchführen.
Möglicherweise könnten die zwischengeschalteten Bibliotheken diese Übersetzung anstelle Ihrer Anwendung durchführen. Ich denke, net.liftweb.record nicht.
Wenn für die betreffenden Felder ein doppelter Typ ausreichen würde, empfehle ich der Einfachheit halber, darauf umzusteigen. Aber vorausgesetzt, Sie verwenden BigDecimal aus guten Gründen, gibt es bekannte Problemumgehungen. Diese sind:
(1) Als Zeichenfolge speichern . Sie können jede beliebige Genauigkeit haben. Das Sortieren oder Abfragen nach exakten Wertübereinstimmungen funktioniert jedoch nur, wenn Sie die linke Seite jedes Mal mit Nullen bis zu einer festen Länge auffüllen. Auch dann sind positive und negative Zahlen zwei unterschiedliche Bereiche in der Sortierung. Die Negative müssen umgekehrt sortiert werden, um eine korrekte numerische Sortierung zu erhalten. Ein Beispiel für die Reihenfolge MongoDB gibt natürlich diese mit Nullen aufgefüllten Zeichenfolgennummern zurück:
"-0000054321.9876"
"-0000100322"
"0000054321.9876"
"0000100322"
Ich glaube, dass der BigDecimal-Typ einen Konstruktor aus einem Zeichenfolgenwert hat, daher ist dies möglicherweise am einfachsten in der Übersetzungsfunktion Ihrer Anwendung zu implementieren.
(2) Speichere es als Shifted Long (Int64) . Sortierung funktioniert, weniger Speicherplatz wird verbraucht, keine Probleme mit negativen vs. positiv. Erfordert das Verschieben der Werte um ein festes Vielfaches, was beim direkten Betrachten der Datenbank etwas unlesbar macht. Die Genauigkeit muss für alle Werte in der gesamten Sammlung gleich sein – OK für finanzielle Anwendungsfälle; nicht OK für einige wissenschaftliche Anwendungsfälle.
(3) Als Zahlenpaar speichern , eine für jede Seite des Dezimalkommas. Das Sortieren erfordert ein wenig zusätzliche Arbeit. Bei Verwendung von Int32-Zahlen ist die Genauigkeit auf 9 Stellen auf beiden Seiten der Dezimalstelle begrenzt. Es ist natürlich etwas mehr Arbeit, zwei Spalten in der Datenbank statt einer zu betrachten.
Für ein Scala-Codebeispiel habe ich gefunden, dass das Reactive-Treiber für das MongoDB-Projekt drei Workarounds für die Serialisierung von BigDecimal . Die erste verwendet doppelt; Die beiden letzteren verfolgen noch einen anderen Ansatz - erstellen Sie ein ganzes Unterdokument für den BigDecimal-Wert. Der Versuch, Werte abzufragen, die in Unterdokumente eingeschlossen sind, wäre schwierig, vermute ich.
Noch eins Fall aus dem wirklichen Leben aus einem Blog des Ebay-Entwicklerteams (Morphia/Java)
P.S. Vielleicht wird MongoDB in Zukunft einen Dezimaltyp hinzufügen. Es gibt eine offene Feature-Anfrage dafür, die Sie ansehen/aufwerten können - https://jira. mongodb.org/browse/SERVER-1393