Skip to content
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

Add OpenAPI-support for rust_decimal? #214

Closed
Christoph-AK opened this issue Feb 24, 2022 · 1 comment
Closed

Add OpenAPI-support for rust_decimal? #214

Christoph-AK opened this issue Feb 24, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@Christoph-AK
Copy link
Contributor

Hey there,
I would love to directly deserialize incoming API requests into rust_decimal::Decimal without precision loss.

Currently with

use rust_decimal::Decimal;

/// Get recipe resource link
#[derive(Object)]
pub struct GetRecipeResourceLink {
    resource: String,
    relative_amount: Decimal,
}

I get the trait bound 'rust_decimal::Decimal: poem_openapi::types::Type' is not satisfied.

Can compatibility for this be added? Maybe behind a feature gate, like in mysql_common?

@Christoph-AK Christoph-AK added the enhancement New feature or request label Feb 24, 2022
@Christoph-AK Christoph-AK changed the title Add OpenAPI-support for rust_decimal Add OpenAPI-support for rust_decimal? Feb 24, 2022
sunli829 added a commit that referenced this issue Mar 1, 2022
@Christoph-AK
Copy link
Contributor Author

Christoph-AK commented Mar 4, 2022

@sunli829 Thanks so much for the quick implementation!

Two observations:

  1. Could you change the serialisation from to_string to normalize? This will give cleaner responses.
  2. Less importantly: I wonder if we can somehow make this a json Number instead of a String. I understand that on one hand while initially parsing a json-string into the json value dictionary some loss of precision could already occur, as the json number is most likely represented as float internally, so letting the value stay a string is possibly the only way to keep complete accuracy. On the other hand this way we lose type safety and compatibility with calling js here - annoying. For now with the normalization this should be good enough and keeping the precision is by far most important, but maybe someone will find a better way to represent this. Or maybe make this accept both a string and a number for now, but output as string only?

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

No branches or pull requests

2 participants