Closed dmoverton closed 4 months ago
Just so we don't get in trouble with this again: are there any other numbers than integers and not integers?
CI fails as well, so that definitely needs to be fixed first, but I like the idea of this PR.
Just so we don't get in trouble with this again: are there any other numbers than integers and not integers?
Looking at the OpenAPI 3 spec, there is an optional format
property which for number
can be float
or double
, and for integer
can be int32
or int64
. We want to use the OpenAPI 3 spec to generate Rust types, so I suspect this extra information would be useful. I'll have a go at that.
The ToSchema
instances in the Haskell openapi3
library actually generate the format
property for the Haskell types Float
, Double
, Int32
and Int64
. Unfortunately, it's not easy for Autodocodec to use those instances.
CI fails as well, so that definitely needs to be fixed first, but I like the idea of this PR.
It's failing with
Error: Unable to locate executable file: cachix
I'm not sure why my changes would be causing that error. Are you able to investigate that?
Looking at the OpenAPI 3 spec, there is an optional format property which for number can be float or double, and for integer can be int32 or int64. We want to use the OpenAPI 3 spec to generate Rust types, so I suspect this extra information would be useful. I'll have a go at that.
In that case we could actually encode this information in the number codec.
Are you able to investigate that?
Yes we probably just need to bump the github actions' versions.
As long as nix flake check
passes, that's fine by me.
Ping @dmoverton
Ping @dmoverton
Hi. I did do some work on using the "format" string for number, but I wasn't completely happy with it and then I got distracted by something else and never got back to it. I'll see if I can get something to you in the next day or so.
@dmoverton Any news?
This has now been implemented in the latest release.
Add a field to the
NumberCodec
that specifies whether or not the value is required to be an integer. The main reason for doing this is to ensure that more precise schemas are generated for OpenAPI, Swagger and JSON Schema.OpenAPI, Swagger and JSON Schema all support
"type": "integer"
as a type specifier, but becauseNumberCodec
was not previously able to differentiate between integral and non-integral types it was generating schemas with"type": "number"
for integral types.