ahl
commented
1 year ago Regarding the use of the oneOf to require exactly one set of properties to be specified, how would you expect that to be rendered in Rust? I've seen some cases like this before and was thinking about something like this:
struct TypeWithXorProperties {
some_prop: String,
one_or_the_other: OneOrTheOther,
}
enum OneOrTheOther {
One(String),
TheOther(u32),
}What do you think?
Regard the latter case:
"ReferenceDef": {
"type": "object",
"oneOf": [
{ "$ref": "#/definitions/GitReference" },
{ "$ref": "#/definitions/ModlinksReference" },
{ "$ref": "#/definitions/LinkReference" }
],
"properties": {
"alternateInstallName": {
"type": "string"
},
"fileType": {
"type": "string",
"enum": ["zip", "dll"]
}
}
},I could imagine modeling that as something like this:
#[serde(untagged)]
enum ReferenceDef {
GitReferenceLink {
#[serde(flatten)]
inner: GitReferenceLink,
alternate_install_name: String,
file_type: ReferenceDefFileType, // enum { Zip, Dll }
},
..
}That is: each variant would include the original type flattened along with the ancillary data. Alternatively we could do something like this:
enum ReferenceDefInner {
GitReferenceLink(GitReferenceLink),
..
}
struct ReferenceDef {
#[serde(flatten)]
inner: ReferenceDefInner,
alternate_install_name: String,
file_type: ReferenceDefFileType,
}That would effectively treat this construct like an implicit allOf: [ { oneOf: [..] }, { properties: {..} } ].
Thoughts?
BadMagic100
When using properties and oneOf together, generation fails. I was using this pattern for a couple use cases:
These can both be worked around fairly trivially (and I think I probably will do that in this case) but these both seem like reasonable cases to handle.
Schema:
cargo typifyoutput: