Comments (14)
Hmm can you also add the resolved versions of OpenAPIKit and Yams, please? cc @mattpolzin
from swift-openapi-generator.
Hmm can you also add the resolved versions of OpenAPIKit and Yams, please? cc @mattpolzin
updated the comment
from swift-openapi-generator.
Strange, when testing against OpenAPIKit directly, I actually get results that would imply the opposite expected result (I would expect with quotes to work and without quotes to fail):
"""
type: null
"""
----
{}
========================
"""
type: 'null'
"""
----
{"type":"null"}
Above I've decoded the first YAML snippet and ended up with an empty schema and a warning. The second YAML snippet decodes to a schema with type
"null"
.
I'm not yet sure what to make of these results.
from swift-openapi-generator.
Sanity checking further, if I use the whole snippets from the OP, I get a schema that has nullable = true
when using the quotes (expected) and I get nullable = false
when not using quotes (expected).
from swift-openapi-generator.
I'm not trying to say the bug report is unreproducible, of course, I am just not seeing any obvious problems in OpenAPIKit's handling of the given schemas yet.
from swift-openapi-generator.
@mattpolzin try to generate from the full json
https://pastebin.com/G8zS0i9u
also, here is complete list of SPM dependencies
from swift-openapi-generator.
Yams also released 5.1.0 with a fix in this area, could it have caused a regression? cc @jpsim
from swift-openapi-generator.
Yams behavior might have changed meaningfully RE this situation, but the results I saw above seemed to indicate that not only did Yams parse the schema alright but OpenAPIKit also represented the schema the way that I expected it to. I still could be missing something obvious on my end, but I wonder if somewhere in the Swift Generator codebase there is an old workaround for "type": null
(i.e. not a valid type, because the type
must be a string) that is causing the observed behavior from the OP to be opposite of what I would expect given what OpenAPIKit is producing.
from swift-openapi-generator.
Actually, 3-4 days ago everythin worked fine, I think there is a bug in a new version of some dependency
from swift-openapi-generator.
@TopIvanAbramov do you have time to try locking down Yams to version 5.0.0 and see if that fixes the problem? If it does, at least we know where to look. IMO that could still either indicate a bug in Yams or a bug in OpenAPIKit or the Swift Generator depending on whether we were just using Yams under a buggy assumption from before.
from swift-openapi-generator.
@mattpolzin Yeah, the problem with Yams 5.1.0 version, on 5.0.0 everything works perfectly
from swift-openapi-generator.
I re-ran my small test case directly against OpenAPIKit using Yams 5.0.6 rather than 5.1.0 and (like you) observed a difference.
With the previous release of Yams, I get the same result whether I quote null
or not (using the snippets from the OP).
With the new release of Yams, I get the differences I described in my previous message.
That said, the behavior as of the new release is the expected behavior. With the previous release, neither snippet is recognized as nullable
. With the new release, the quoted "null"
is parsed correctly and the schema containing that type is marked nullable
by OpenAPIKit.
All that to say, I think what we have here is a new (correct) case to handle rather than a new bug to work around.
from swift-openapi-generator.
@TopIvanAbramov could you elaborate on the correct and incorrect behavior for this ticket? When things work as expected, what is being generated?
I'm wondering if the desired behavior occurs when an anyOf
schema has an empty non-nullable fragment in it and the undesired behavior occurs when that same anyOf
schema has an empty nullable fragment in it since that appears to be the only difference I can spot in what OpenAPIKit produces with the new version of Yams.
Put into JSON to remove ambiguity, OpenAPIKit is telling the Swift generator about the following when null
is not quoted:
{
"type": "object",
"properties": {
"given_name": {
"title": "Given Name",
"anyOf": [
{
"type": "string"
},
{}
]
}
}
}
In this case, it tells the Swift generator that given_name
is not nullable
. This is the situation producing the desired results.
Whereas when null
is quoted, it tells the Swift generator about the following:
{
"type": "object",
"properties": {
"given_name": {
"title": "Given Name",
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"type": "null"
}
}
}
In this case, it tells the Swift generator that given_name
is nullable
. This is the situation producing the undesired results.
I do see a problem with the JSON that OpenAPIKit produces there (the "type": "null"
living outside the anyOf
) but that's just a serialization problem; the representation that the Swift generator gets is simply marked nullable
.
from swift-openapi-generator.
@TopIvanAbramov Note that type:
needs to be followed by a string (or an array), according to JSON Schema 2020-12, which we use here to parse OpenAPI 3.1. So type
being null
(as opposed to "null"
) is not a valid schema, and if it was parsed successfully previously, that'd be considered a bug.
If you property quote it as "null"
- do you now get the desired or non-desired behavior? We can debug it from here.
from swift-openapi-generator.
Related Issues (20)
- Logging and HTTPBody HOT 3
- Merging oneOf with many compatible enums of a single value HOT 10
- anyOf encoder does not include discriminator's `parameterName` leading to incorrect encoding HOT 2
- Is there a workaround to deal with slow compilation times for a very large openapi file? HOT 3
- Empty arrays are omitted from query params HOT 5
- Support for `multipart/mixed`? HOT 1
- When a delete path do not have responses content an error generated HOT 2
- Add ability to attach protocols to generated models HOT 9
- Protocol where each `Output` conforms to HOT 3
- Make the generator usable on very big specs HOT 3
- Old and new examples HOT 3
- visionOS can't use HOT 4
- How to convert the binary obtained from the server into a playable Data type? HOT 2
- HTTPTypes linker error if multiple targets use open API generator HOT 2
- Getting "any has no effect on concrete type 'Error'" HOT 6
- Need to be able to support multiple OpenAPI specs HOT 2
- Tutorial doc text color issue on light theme HOT 1
- Check for updated spec before generating HOT 2
- Warnings due to `@frozen` attribute on non-public enums with Xcode 16 Beta 3 HOT 3
- Support multiple contentTypes in encoding multipart/form-data HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from swift-openapi-generator.