Ho dei problemi ad usare ransack per le ricerche in campi che
contengono stringhe rappresentanti importi, soldi.
Avevo deciso di utilizzare le stringhe in modo da poter inserire
valori come 258.000, 1.033.000,00, cioe’ valori in euro.
Ora pero’ devo fare delle ricerche su questi campi e mi trovo in
difficolta’ poiche’ ransack chiede interi e i confronti con le
stringhe suddette non producono i risultati richiesti.
Ad esempio se cerco un valore minore o uguale a 2 mi tira fuori il
valore del campo che contiene 1.033.000,00.
Forse ho sbagliato ad usare stringhe per rappresentare i valori in euro?
Ciao, personalmente non avrei rappresentato sul database un numero come
stringa.
Stefano
2012/2/14 Mauro [email protected]
2012/2/14 Stefano P. [email protected]:
Ciao, personalmente non avrei rappresentato sul database un numero come
stringa.
effettivamente, DECIMAL pi adatto, se il tuo db non ha un tipo MONEY
–
twitter: @riffraff
blog (en, it): www.riffraff.info riffraff.blogsome.com
work: cascaad.com circleme.com
2012/2/14 gabriele renzi [email protected]:
2012/2/14 Stefano P. [email protected]:
Ciao, personalmente non avrei rappresentato sul database un numero come
stringa.effettivamente, DECIMAL pi adatto, se il tuo db non ha un tipo MONEY
Uso postgres come db.
2012/2/14 Riccardo T. [email protected]:
Questa gem e
il massimo in termini di valuta e multicurrency. Ovviamente euna cattiva idea usare stringhe per la valuta e purtroppo
the ne sei accorto. Le risposte sul tipo da usare in Rails per la valuta
sono:
Gia’ me ne sono accorto 
:decimal, :precision => 8, :scale => 2
:decimal, :precision => 15, :scale =2
Per adesso sembra essermi sufficente, vediamo piu’ in la’.
Il punto e’ che nei campi del form l’utente per un valore in euro di,
ad esempio, 1.033.000,00, deve inserire 1033000.00, prevedo problemi.
Questa gem eil massimo in termini di valuta e multicurrency. Ovviamente e una cattiva idea usare stringhe per la valuta e purtroppo
the ne sei accorto. Le risposte sul tipo da usare in Rails per la valuta
sono:
:decimal, :precision => 8, :scale => 2
Ovviamente ci sono gli helper per formattarlo in base al formato locale
(virgola invece che punto…). La tecnica che usa la gem Money e
utilizzare gli interi, perche` quando ci fai le operazioni no hai errori
di arrotondamento, ovviamente devi immagazzinare il dato in centesimi,
che poi siano Euro, pound o dollari poco importa. Per visualizzare i
centesimi con l’euro basta dividere per cento ed utilizzare la virgola
invece del punto tutto qui.
Fossi in te aggiungerei un nuovo campo tipo intero e migrerei i dati li,
in centesimi.
E’ consuetudine utilizzare un tipo numerico per rappresentare valori
monetari.
La scelta pi logica sarebbe un valore decimale, ma poich storicamente i
decimali soffrono di precision loss, questo li rende assolutamente
inappropriati per le transazioni finanziarie. Potreste trovarvi a fine
anno
con qualche decina d’euro, o peggio ancora, centinaia di euro mancanti.
Questo problema non esiste se i valori non vengono sottoposti a calcoli
che
richiedono arrotondamenti dato che non c’ pericolo di precision loss.
In tutti gli altri casi, uso e consuetudine gestire i valori monetari
come interi in centesimi e costruire una libreria che esponga
all’esterno
un’interfaccia in grado di comunicare invece con il valore intero.
Ecco un esempio
https://rubygems.org/gems/money
2012/2/14 Mauro [email protected]
:decimal, :precision => 15, :scale =2
Per adesso sembra essermi sufficente, vediamo piu’ in la’.
Il punto e’ che nei campi del form l’utente per un valore in euro di,
ad esempio, 1.033.000,00, deve inserire 1033000.00, prevedo problemi.
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos
On Tue, Feb 14, 2012 at 1:11 PM, Simone C. [email protected]
wrote:
La scelta pi logica sarebbe un valore decimale, ma poich storicamente i
decimali soffrono di precision loss, questo li rende assolutamente
inappropriati per le transazioni finanziarie. Potreste trovarvi a fine anno
con qualche decina d’euro, o peggio ancora, centinaia di euro mancanti.
Mi pare che il tipo BigDecimal di ruby (in cui vengono restituiti ad
esempio da ActiveRecord i dati letti da colonne decimal nel db) non
abbia problemi di arrotondamento (a differenza del tipo float):
“BigDecimal provides arbitrary-precision floating point decimal
arithmetic.”
Questo problema non esiste se i valori non vengono sottoposti a calcoli che
richiedono arrotondamenti dato che non c’ pericolo di precision loss.
Non sono sicuro sui calcoli eseguiti dal database (all’interno di
query SQL) perche’ puo dipendere dall’implementazione del db, ma per i
calcoli fatti in ruby se tutti i numeri sono BigDecimal non dovresti
comunque avere problemi di arrotondamento
In tutti gli altri casi, uso e consuetudine gestire i valori monetari
come interi in centesimi e costruire una libreria che esponga all’esterno
un’interfaccia in grado di comunicare invece con il valore intero.
si e ci sono anche vari casi in cui occorre una precisione maggiore di
quella al centesimo! Ad esempio i tassi di cambio sono su 6 cifre
decimali o i “calcoli intermedi” che dovrebbero essere fatti su 5
cifre decimali:
http://www.simone.it/newdiz/newdiz.php?action=view&dizionario=7&id=17
ciao,
Luca
On Tue, Feb 14, 2012 at 2:18 PM, Simone C. [email protected]
wrote:
BigDecimal una buona soluzione ma non una implementazione Ruby, non un
valore nativo ad esempio di un database.
Quando salverai i dati nel database dovrai comunque scegliere una
rappresentazione. A quel punto, salvarli stringa comporta il problema di
sorting citato prima.
hai ragione, infatti non consigliavo di usare le stringhe 
In MySQL
puoi usare le colonne DECIMAL che sono una buona rappresentazione per
i numeri decimali (ti permette di scegliere la precisione), oppure una
colonna INTEGER (memorizzando centesimi o millesimi o decimillesimi di
euro …)
ma alla fine quello che conta nella scelta della rappresentazione di
un numero sono le operazioni che si devono fare su quel numero, quello
che il numero modella.
Luca
BigDecimal una buona soluzione ma non una implementazione Ruby, non un
valore nativo ad esempio di un database.
Quando salverai i dati nel database dovrai comunque scegliere una
rappresentazione. A quel punto, salvarli stringa comporta il problema di
sorting citato prima.
2012/2/14 Luca M. [email protected]
abbia problemi di arrotondamento (a differenza del tipo float):
calcoli fatti in ruby se tutti i numeri sono BigDecimal non dovresti
http://www.simone.it/newdiz/newdiz.php?action=view&dizionario=7&id=17ciao,
Luca
Ml mailing list
[email protected]
http://lists.ruby-it.org/mailman/listinfo/ml
–
Simone C.
Application Developer
Site & Blog: http://www.simonecarletti.com
Email: [email protected]
LinkedIn: http://linkedin.com/in/weppos
Skype: weppos