Improves OpenAPI spec names and types and error reporting#40
Merged
Conversation
This uses the new `json-fleece` API to improve the names and types given to OpenAPI specs. This includes a change that restricts the characters allowed in the name of an OpenAPI spec. This default is to allow alphanumeric characters, plus '.' and '_'. The list of allowed characters can be specified both via the various functions that build OpenAPI specs and the default command line generation command. This also improves the error reporting when schemas have conflicts or bad names to try to provide context of where the offending spec is contained within the spec definitions so that the developer can more easily locate the offending specs within the code.
OwenGraves
approved these changes
Dec 12, 2025
Comment on lines
+1060
to
+1069
| FleeceOpenApi $ Right . mkPrimitiveSchema "number" OpenApi.OpenApiNumber | ||
|
|
||
| text = | ||
| FleeceOpenApi . Right $ mkPrimitiveSchema "text" OpenApi.OpenApiString | ||
| FleeceOpenApi $ Right . mkPrimitiveSchema "text" OpenApi.OpenApiString | ||
|
|
||
| boolean = | ||
| FleeceOpenApi . Right $ mkPrimitiveSchema "boolean" OpenApi.OpenApiBoolean | ||
| FleeceOpenApi $ Right . mkPrimitiveSchema "boolean" OpenApi.OpenApiBoolean | ||
|
|
||
| null = | ||
| FleeceOpenApi . Right $ mkPrimitiveSchema "null" OpenApi.OpenApiNull | ||
| FleeceOpenApi $ Right . mkPrimitiveSchema "null" OpenApi.OpenApiNull |
There was a problem hiding this comment.
Just out of curiosity, what's the motivation for this swap?
Member
Author
There was a problem hiding this comment.
The type of FleeceOpenApi changed from Either OpenApiError SchemaInfo to Path -> Either OpenApiError SchemaInfo. To accommodate that change here mkPrimitiveSchema now takes the Path as its last parameter. For the types to work out here, Right needs to be composed with mkPrimitiveSchema to make the Path -> Either OpenApiError SchemaInfo function that FleeceOpenApi now takes as its argument. Composing FleeceOpenApi . Right no longer works with the new types.
Comment on lines
-1162
to
-1163
| "UTCTime" -> setSchemaInfoFormat "date-time" $ mkPrimitiveSchema "string" OpenApi.OpenApiString | ||
| "Day" -> setSchemaInfoFormat "date" $ mkPrimitiveSchema "string" OpenApi.OpenApiString |
There was a problem hiding this comment.
Where did this behavior get refactored to, is it inside of fleece now?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This uses the new
json-fleeceAPI to improve the names and typesgiven to OpenAPI specs.
This includes a change that restricts the characters allowed in the name
of an OpenAPI spec. This default is to allow alphanumeric characters, plus
'.' and '_'. The list of allowed characters can be specified both via
the various functions that build OpenAPI specs and the default command
line generation command.
This also improves the error reporting when schemas have conflicts or
bad names to try to provide context of where the offending spec is
contained within the spec definitions so that the developer can more
easily locate the offending specs within the code.