-
Notifications
You must be signed in to change notification settings - Fork 96
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
Collapse anyOf
with only one option?
#296
Comments
If this proposal is acceptable, I am happy to implement such a thing, also happy to hide it behind a flag. |
@omissis any thoughts on this? Happy to start work ASAP if you are OK with the idea. |
Hey, I think that while this approach might be considered attractive for one-child AnyOfs, it exposes the client code that is using the generated code to breaking changes in those cases where the AnyOfs eventually evolve to contain more than one item: for this reason I am not very keen on going down this path. |
@omissis wouldn't the transition from a one-length anyOf to a n-length anyOf just mean that the generated code would change from something like type Thing struct {
Member MemberType `json:"member"`
}
type MemberType struct {
Field string
} To something like the current generation, which is type Thing struct {
Member any `json:"member"`
}
type MemberType struct {
Field string
} In what cases would this be breaking for consuming code? Naively I was expecting no impact for some consumer like: func main() {
myThing := Thing{
Member: MemberType{
Field: "whoa",
},
}
} For example, on the playground Changes from a one-length anyOf to some other one-length anyOf would be breaking, yes, but they would be breaking regardless if that were the true intent of the schema (and in the current generation, this break would not be caught by the compiler!) |
@omissis thoughts? On coding this I realized we just ignore these fields today. The update would be trivial: $ git diff -- pkg/generator/schema_generator.go
diff --git a/pkg/generator/schema_generator.go b/pkg/generator/schema_generator.go
index 25bea18..24d384c 100644
--- a/pkg/generator/schema_generator.go
+++ b/pkg/generator/schema_generator.go
@@ -704,6 +704,12 @@ func (g *schemaGenerator) generateTypeInline(
}
}
+ for _, collection := range [][]*schemas.Type{t.AllOf, t.AnyOf, t.OneOf} {
+ if len(collection) == 1 {
+ return g.generateDeclaredType(collection[0], scope)
+ }
+ }
+
typeIndex := 0
var typeShouldBePointer bool Please let me know what backwards compatibility issues you forsee - I hope my comment above helps to show my thinking. Simple summary:
I believe some upstream tooling that generates JSON Schemas from e.g. .NET applications may be incorrectly using |
@omissis any thoughts here? |
If I have a schema like:
In a sense, it's equivalent to:
For users that generate Go types using a JSONSchema they do not control, the use of
anyOf
in the above example will generate[]interface{}
, which is unfortunate and very much so not ergonomic, either on generation or parsing. Would it be acceptable to generate a Gostruct
in these cases with a definite type for the slice, even if that is not perfectly what the author of the JSONSchema intended?I am not sure, but it seems like there may be some other tool that generates these "loose" JSONSchemas with
anyOf
array items with only one type, perhaps also a bug in that generator. Would be awesome to work around such cases on the consumer end with this tool.The text was updated successfully, but these errors were encountered: