What problem are you trying to solve?
Currently all money amounts are floating points (floats). They should be decimal types because decimal provides exact base-10 precision, which is required for financial calculations. Floating-point types (float and double) store values in binary, meaning many decimal fractions (such as 0.1) cannot be represented exactly. The decimal type is specifically designed for working with currency values.
Proposed solution
Update the 'format' property of the Sumup Open API spec to 'decimal' for money properties to allow consumers to generate proper currency safe types.
An example: https://github.com/sumup/sumup-openapi/blob/754237a94d8badea0f7e209c977b94cc95347f05/openapi.json#L5792
The format property is an open string property, can have any value, and it is up to generators to consume the 'format' property.
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#data-types
Alternatives considered
Alternatives I have considered is changing the generator.go with a workaround to determine what properties should be decimal. If the SumUp Open API spec cannot be changed perhaps we could have a way to determine which properties should be decimal around the "number" section of the genrator.
|
case schemaHasType(schema, "number"): |
Use case
This would help financial values keep their precision and avoid floating point rounding errors.
Additional context
No response
What problem are you trying to solve?
Currently all money amounts are floating points (floats). They should be decimal types because decimal provides exact base-10 precision, which is required for financial calculations. Floating-point types (float and double) store values in binary, meaning many decimal fractions (such as 0.1) cannot be represented exactly. The decimal type is specifically designed for working with currency values.
Proposed solution
Update the 'format' property of the Sumup Open API spec to 'decimal' for money properties to allow consumers to generate proper currency safe types.
An example: https://github.com/sumup/sumup-openapi/blob/754237a94d8badea0f7e209c977b94cc95347f05/openapi.json#L5792
The format property is an open string property, can have any value, and it is up to generators to consume the 'format' property.
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md#data-types
Alternatives considered
Alternatives I have considered is changing the generator.go with a workaround to determine what properties should be decimal. If the SumUp Open API spec cannot be changed perhaps we could have a way to determine which properties should be decimal around the "number" section of the genrator.
sumup-dotnet/codegen/internal/generator/generator.go
Line 1395 in b238fb3
Use case
This would help financial values keep their precision and avoid floating point rounding errors.
Additional context
No response