A partire da MongoDB v2.6 non esiste un tipo decimale a cifre fisse. I dati devono essere salvati in un campo di tipo diverso e l'applicazione deve eseguire la traduzione ogni volta.
Potenzialmente le librerie intermedie potrebbero eseguire questa traduzione invece della tua applicazione. Immagino che net.liftweb.record non lo faccia.
Se un tipo doppio fosse sufficiente per i campi in questione, consiglio di passare a quello per semplicità. Ma supponendo che tu stia usando BigDecimal per buoni motivi, ci sono soluzioni alternative ben note. Questi sono:
(1) Memorizzalo come una stringa . Puoi avere qualsiasi precisione arbitraria. Ma l'ordinamento o l'interrogazione per le corrispondenze di valori esatti funzionerà solo se si riempie il lato sinistro con zeri a una lunghezza fissa ogni volta. Anche allora i numeri positivi e negativi sono due intervalli diversi per quanto riguarda l'ordinamento. I negativi devono essere ordinati al contrario per avere un ordinamento numerico corretto. Un esempio dell'ordine MongoDB restituirà naturalmente questi numeri di stringa con riempimento zero:
"-0000054321.9876"
"-0000100322"
"0000054321.9876"
"0000100322"
Credo che il tipo BigDecimal abbia un costruttore da un valore stringa, quindi questo potrebbe essere il più semplice da implementare nella funzione di traduzione della tua applicazione.
(2) Memorizza come long spostato (Int64) . L'ordinamento funziona, viene utilizzato meno spazio su disco, nessun problema con negativo vs. positivo. Richiede lo spostamento dei valori verso l'alto di un multiplo fisso che rende un po' illeggibile quando si guarda direttamente il database. La precisione deve essere fissata in modo che sia la stessa per tutti i valori dell'intera raccolta:OK per i casi di utilizzo finanziario; non va bene per alcuni casi d'uso scientifici.
(3) Memorizza come coppia di numeri , uno per entrambi i lati della virgola decimale. L'ordinamento richiede un po' di lavoro in più. Se si utilizzano numeri Int32, la precisione sarà limitata a 9 cifre su entrambi i lati del decimale. Guardare due colonne nel db invece di una è un po' più di lavoro ovviamente.
Per un esempio di codice Scala ho scoperto che il driver reattivo per il progetto MongoDB ha documentato tre soluzioni alternative per la serializzazione per BigDecimal . Il primo usa il doppio; gli ultimi due adottano ancora un altro approccio:creano un intero documento secondario per il valore BigDecimal. Sospetto che provare a interrogare i valori racchiusi in documenti secondari sarebbe complicato.
Un altro caso reale da un blog del team di sviluppo di Ebay (Morphia/Java)
PS forse MongoDB aggiungerà un tipo decimale in futuro. C'è una richiesta di funzionalità aperta che puoi guardare/upvotare - https://jira. mongodb.org/browse/SERVER-1393
