You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Serialization / Deserialization of Rust Decimals has been a pain point for developing against this library simply because there are many different behaviors that developers need to support for a decimal type. For example:
String serialization / deserialization
An empty string treated as zero vs None vs error
Float-like serialization / deserialization. In addition, arbitrary precision support when using JSON.
A mixture of the above (e.g. sometimes string, sometimes float)
Field level configuration vs project level configuration.
etc
The matrix of options, as well as keeping track of what is supported and when can get confusing.
Option 1
I'd like v2 of this to be a little more policy driven - perhaps leveraging macros. One potential option for this is to make generation/utilization of transparent types a bit easier. That way, you could define the type for the API and then deref when required. e.g.
Could generate an implementation of the Serialize, Deserialize traits as well as any other helpful patterns. It'd allow full customizability at a project by project level (as well as potentially field by field).
One downside: it could become annoying if you had multiple types you needed to generate to support different APIs potentially.
The text was updated successfully, but these errors were encountered:
Problem
Serialization / Deserialization of Rust Decimals has been a pain point for developing against this library simply because there are many different behaviors that developers need to support for a decimal type. For example:
None
vs errorThe matrix of options, as well as keeping track of what is supported and when can get confusing.
Option 1
I'd like v2 of this to be a little more policy driven - perhaps leveraging macros. One potential option for this is to make generation/utilization of transparent types a bit easier. That way, you could define the type for the API and then deref when required. e.g.
Could generate an implementation of the
Serialize
,Deserialize
traits as well as any other helpful patterns. It'd allow full customizability at a project by project level (as well as potentially field by field).One downside: it could become annoying if you had multiple types you needed to generate to support different APIs potentially.
The text was updated successfully, but these errors were encountered: