Skip to content

move float api value from String to Double in our model #32

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jetmore opened this issue Jan 25, 2023 · 1 comment
Open

move float api value from String to Double in our model #32

jetmore opened this issue Jan 25, 2023 · 1 comment

Comments

@jetmore
Copy link
Contributor

jetmore commented Jan 25, 2023

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)
@jetmore
Copy link
Contributor Author

jetmore commented Jan 25, 2023

Worth noting code that uses the client would need to change, but right now GF is the only user and I think it's worth changing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant