There are several values in possible SM api responses that return float values (list at bottom). Some of these are returned as numeric values in the api (eg, from Address, "lat": 24.923) and some are returned as strings (eg, from Invoice, "lat": 24.923). These were implemented in our model as Strings. Suggest moving these to a different type. The obvious answer (and correct one for non-dollar amounts) is Double. We could use Double for monetary fields also, but we could also use a more-money-specific type. GF uses BigDecimal internally and that seems to be a pretty standard solution. I'm inclined to leave them as Double though since these are single values and let the user of the library convert to BigDecimal if they need to do monetary math on the values
Address
lat
lng
Invoice
balance_due (s)
total_paid (s)
LineItem
unit_code (s)
quantity (s)
tax_rate (s) (previously unimplemented, choosing to implement as Double for #31)
tax_amount (s) (previously unimplemented, choosing to implement as Double for #31)
subtotal (s) (previously unimplemented, choosing to implement as Double for #31)
total (s) (previously unimplemented, choosing to implement as Double for #31)
Payment
amount (s)
Upload
file_size (s)
There are several values in possible SM api responses that return float values (list at bottom). Some of these are returned as numeric values in the api (eg, from Address,
"lat": 24.923) and some are returned as strings (eg, from Invoice,"lat": 24.923). These were implemented in our model as Strings. Suggest moving these to a different type. The obvious answer (and correct one for non-dollar amounts) is Double. We could use Double for monetary fields also, but we could also use a more-money-specific type. GF uses BigDecimal internally and that seems to be a pretty standard solution. I'm inclined to leave them as Double though since these are single values and let the user of the library convert to BigDecimal if they need to do monetary math on the values