I tried to generate server code using Redfish OpenAPI schema but failed. Wonder if anyone has tried this recently?
The error is about multiple object definitions with same name and indirectly reference.
[main] INFO o.o.codegen.DefaultGenerator - Model Error not generated since it's a free-form object Exception in thread "main" java.lang.StackOverflowError at org.openapitools.codegen.utils.ModelUtils.hasOrInheritsDiscriminator(ModelUtils.java:1327) at org.openapitools.codegen.utils.ModelUtils.hasOrInheritsDiscriminator(ModelUtils.java:1338) ... The same error can be reproduced with a set of simplified yaml files in github.com/ztai-goog/bugreport/tree/master/openapi_codegen_1 and run the generator command below. docker run --rm \ -v $PWD:/local openapitools/openapi-generator-cli generate \ -i /local/petstore.yaml \ -g go-server \ -o /local/go_server
I haven't tried server-side code; most of my experience with the OpenAPI tools have been with documentation generation, which has been successful for me the last time I tried.
The last time I tried any sort of code generation was pretty early on when the tools didn't really have complete support for external references (or so it seemed to me at the time). I can certainly take a closer look at things now that they should be in a more mature state.
From what your describing, is the issue that "TestType" is defined in both A.yaml and C.yaml? Is there any documented restriction about this? I would think that since the references call out the entire path to the definition, there shouldn't be any restrictions like that.
In the example you have, petstore.yaml makes the following two references:
TestType within A.yaml, which has its full definition there
TestType within B.yaml, which then references TestType in C.yaml, and the full definition is found there
I'm assuming that the issue is because "TestType" is defined in multiple places. However, all cases, the references are very direct and there's nothing circular about it; ultimately the reference line terminates at a final definition.
What I'd like to understand before addressing this is if there's an issue with the OpenAPI tools in assuming that all definition names are unique, or if this is a requirement in the OpenAPI spec. From a specification perspective, I cannot find any text that requires this. The closest thing I can find is in the JSON Schema spec, which I know OpenAPI heavily uses:
Vocabularies may be defined by any entity. Vocabulary authors SHOULD take care to avoid keyword name collisions if the vocabulary is intended for broad use, and potentially combined with other vocabularies. JSON Schema does not provide any formal namespacing system, but also does not constrain keyword names, allowing for any number of namespacing approaches.
I forgot one other thing that needs to be done; when you extract the 8010 bundle, you will need to delete the Volume and VolumeCollection schemas from the json-schema folder. "rm Volume*" should do the trick. Volume is currently managed by SNIA, which also has several references to other SNIA schemas, which makes the conversion complex for this testing.
The change is basically to prefix file name to the type names so that they won't all have the same name.
Currently it requires a few extra steps before it can be generated.
I understand changing schema isn't an easy thing to do, especially when there are many versions and cases where a type can be one of many types/versions. Could you please let me know the plan forward to address this issue?
Yes, exactly; the generators seem to make a flat list of everything, so it also seemed like we needed to make all of the definition names unique.
If the changes look good to you and address your issue, we'll take that feedback into the forum and see how we can logistically do something like this for future releases. Ultimately I would prefer users to simply download and use the 8010 bundle as-is and not require them to do further processing of the schema. I just needed you to do that for the time being to make sure the changes I made fixed your issue.
Another issue is related Enum declaration. Running `go build` in the generated server code fails because enums of same name have been declared in multiple files.
The error looks like
$ go build # github.com/GIT_USER_ID/GIT_REPO_ID/go go/model_account_service_v1_7_1_account_provider_types.go:19:2: OEM redeclared in this block previous declaration at go/model_acceleration_function_v1_0_2_acceleration_function_type.go:23:57 go/model_account_service_v1_7_1_authentication_types.go:19:2: OEM redeclared in this block previous declaration at go/model_account_service_v1_7_1_account_provider_types.go:19:47 ... ...
Great, thanks for testing this further. I'll merge your change into my working branch.
The new error confused me a bit... "OEM" isn't the name of the enumeration, but rather it's a value in an enumeration (and one that we reuse in many places). I'm not sure why having the same enumeration value in different enumerations would be bad... I'll do some more digging on this.
It seems the type generation is unlikely to work properly for redfish schema.
I've tried the following languages Go: Issues we already know Python: Generator fails for some of the pattern regex strings Rust: Free-form objects are not generated but they are still referenced by other generated type structs NodeJs: No type generation, no router wiring.
It's probably safe to say, better avoid type generation for now. Without automatic type generation or serialization/deserialization, Node/Js is likely an easier choice.