Skip to content
New issue

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

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

Already on GitHub? # to your account

Serialization V2 - brainstorming #611

Open
paupino opened this issue Sep 26, 2023 · 1 comment
Open

Serialization V2 - brainstorming #611

paupino opened this issue Sep 26, 2023 · 1 comment
Labels

Comments

@paupino
Copy link
Owner

paupino commented Sep 26, 2023

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:

  • 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.

#[decimal_serde(serialize = "string", deserialize = "float_or_string")]
struct DecimalLike(Decimal);

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.

@KKould
Copy link

KKould commented Sep 28, 2023

Hope to add Memory Comparable, many KV-based databases can use Memory Comparable to create naturally ordered indexes.

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

No branches or pull requests

3 participants