Skip to content
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

Schema type Object with OneOf #64

Closed
tiagolobocastro opened this issue Dec 29, 2022 · 7 comments
Closed

Schema type Object with OneOf #64

tiagolobocastro opened this issue Dec 29, 2022 · 7 comments
Assignees

Comments

@tiagolobocastro
Copy link
Contributor

Hi, I seem to have hit a little snag with this kind of schema:

    ABC:
      type: object
      properties:
        a:
          $ref: '#/components/schemas/A'
        b:
          $ref: '#/components/schemas/B'
        c:
          $ref: '#/components/schemas/C'
      oneOf:
        - required:
            - a
        - required:
            - b
        - required:
            - c

SchemaKind::Type and SchemaKind::OneOf are different derivations so I guess this is not currently supported?

@ahl
Copy link
Collaborator

ahl commented Oct 20, 2023

It deserializes like this:

Schema {
    schema_data: SchemaData {
        nullable: false,
        read_only: false,
        write_only: false,
        deprecated: false,
        external_docs: None,
        example: None,
        title: None,
        description: None,
        discriminator: None,
        default: None,
        extensions: {},
    },
    schema_kind: Any(
        AnySchema {
            typ: None,
            pattern: None,
            multiple_of: None,
            exclusive_minimum: None,
            exclusive_maximum: None,
            minimum: None,
            maximum: None,
            properties: {},
            required: [],
            additional_properties: None,
            min_properties: None,
            max_properties: None,
            items: None,
            min_items: None,
            max_items: None,
            unique_items: None,
            enumeration: [],
            format: None,
            min_length: None,
            max_length: None,
            one_of: [],
            all_of: [],
            any_of: [],
            not: None,
        },
    ),
}

@ahl ahl closed this as completed Oct 20, 2023
@tiagolobocastro
Copy link
Contributor Author

It doesn't get deserialised into Any, it gets deserialised into Object

@ahl ahl reopened this Oct 21, 2023
@ahl
Copy link
Collaborator

ahl commented Oct 21, 2023

you're right (of course). my test program was flawed and I made a hasty conclusion. Sorry!

@ahl ahl self-assigned this Oct 21, 2023
@ahl ahl closed this as completed Oct 21, 2023
@tiagolobocastro
Copy link
Contributor Author

I guess I don't really understand this then, so the schema type we have in rust does not correlate to the openapi type field?
I'll try to give this a try soonish.
Btw, would it be possible to expose that RawSchema rather than the schemaKind?

@ahl
Copy link
Collaborator

ahl commented Oct 25, 2023

I'm not sure why exactly this design choice was made in openapiv3, but if you look e.g. at schemars::schema::SchemaObject it's just everything lumped together. It initially seemed useful to me (bear in mind, I didn't write this crate initially), but over time it's seemed more of a nuisance than a utility since it just bifurcates common cases from uncommon--but not rare--cases.

I'm going to build a 3.1 crate at some point and will represent the Schema more like what we see in schemars.

@tiagolobocastro
Copy link
Contributor Author

Another crate I had looked at also does that (lumped things together), though also this way with different types seemed better to me as well :D
By 3.1 you mean openapi 3.1? Will the crate still be compatible with 3.0.x ?

@ahl
Copy link
Collaborator

ahl commented Oct 25, 2023

Yeah that would be my intention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants