Support for AnyOf and discriminators

[uri200]

Hello,

I see none of the all available swagger go generators are capable to handle AnyOf and Discriminators. Those two object types are used a lot on 3gpp 5g specifications, so teams building 5g services using go and swagger can't not use those generators.

I see this issue is tracked on the roadmap. Is there any progress on that end? If there were any beta I would be up for testing it

Thanks!

[shadowspore]

Hello
We actually already have anyOf and discriminators support.
Please give ogen a try, and send an example api schema if it doesn't work.

[uri200]

Hey @shadowspore thanks

I tried it with this command

//go:generate go run github.com/ogen-go/ogen/cmd/ogen --target trafficInfluence -package trafficInfluence --clean openapi.yaml

The error you can see below seems to be caused due to the anyOf construction in here. It looks like that for some reason two different types have the same name(???).

I am trying to debug step by step and lead me here but I am still trying to figure out what this function is doing. Any help would be appreciated to understand the issue.

(note the complete yaml file is attached. Note that this is a 5g spec so the idea is not to modify the spec since it is standard)

      anyOf:
      - not:
          required:
          - subscribedEvents
      - required:
        - notificationDestination

ERROR:

╰─ ./ogen -target trafficInfluence -package trafficInfluence --clean openapi.yaml
INFO	schemagen	Type is not defined, using any	{"at": "openapi.yaml:911:9", "name": "TrafficInfluSub0"}
INFO	schemagen	Type is not defined, using any	{"at": "openapi.yaml:914:9", "name": "TrafficInfluSub1"}
generate:
    main.run
        /Users/obatalla/testgit/ogen/cmd/ogen/main.go:183
  - build IR:
    main.generate
        /Users/obatalla/testgit/ogen/cmd/ogen/main.go:53
  - make ir:
    github.com/ogen-go/ogen/gen.NewGenerator
        /Users/obatalla/testgit/ogen/gen/generator.go:59
  - path "/{afId}/subscriptions": get:
    github.com/ogen-go/ogen/gen.(*Generator).makeIR
        /Users/obatalla/testgit/ogen/gen/generator.go:91
  - responses:
    github.com/ogen-go/ogen/gen.(*Generator).generateOperation
        /Users/obatalla/testgit/ogen/gen/gen_operation.go:49
  - 200:
    github.com/ogen-go/ogen/gen.(*Generator).generateResponses
        /Users/obatalla/testgit/ogen/gen/gen_responses.go:54
  - contents:
    github.com/ogen-go/ogen/gen.(*Generator).responseToIR
        /Users/obatalla/testgit/ogen/gen/gen_responses.go:183
  - application/json:
    github.com/ogen-go/ogen/gen.(*Generator).generateContents
        /Users/obatalla/testgit/ogen/gen/gen_contents.go:338
  - generate schema:
    github.com/ogen-go/ogen/gen.(*Generator).generateContents.func1
        /Users/obatalla/testgit/ogen/gen/gen_contents.go:186
  - item:
    github.com/ogen-go/ogen/gen.(*schemaGen).generate2
        /Users/obatalla/testgit/ogen/gen/schema_gen.go:250
  - anyOf:
    github.com/ogen-go/ogen/gen.(*schemaGen).generate2
        /Users/obatalla/testgit/ogen/gen/schema_gen.go:101
  - collect variants:
    github.com/ogen-go/ogen/gen.(*schemaGen).anyOf
        /Users/obatalla/testgit/ogen/gen/schema_gen_sum.go:144
  - TrafficInfluSub:
    github.com/ogen-go/ogen/gen.(*schemaGen).collectSumVariants
        /Users/obatalla/testgit/ogen/gen/schema_gen_sum.go:120
  - sum types with same names not implemented

openapi.yaml.zip

[uri200]

Maybe it would be a good idea to add a flag to disable all the anyOF, allOf, oneOf, and not. This way the tool could generate the code to unblock people who wants to use it. The checks for all the anys could be done by the application

[ernado]

cc @tdakkota

[markettes]

Is there any news about support for complex anyOf?

[jvatic]

I've been encountering cases where anyOf is used in a spec where oneOf would have made more sense (only one option should ever match and all options are self-contained). It also seems to me that the strategies for oneOf should also be applicable to anyOf (and indeed the two already share some implementation logic)—if only one schema matches, then we don't need to worry about merging and such anyOfs can follow simpler code-paths.

Does this sound sensible? One potential drawback of doing this would be that if an anyOf that can behave as a oneOf is updated for that to no longer be true then (assuming there's support for it) the generated code may be significantly different vs incrementally different.