Open zorba128 opened 4 months ago
Also note what would happen if specification would not only require presence of discriminator field in product schemas, but also require those to be constrained with const
. In that case the whole part of specs related to discriminator mappings would become unnecessary. No need to specify mappings, no need to assume "schema name is used by default".
Discriminator could just simply point at name of property, and validator/codec generator can actually discover actual mapping just looking at discriminator name, and traversing schemas listed in oneOf
.
I think this would simplify specs alot.
I'm actually trying to fix openapi/asyncapi generation for my project, and got stuck a bit looking at examples in the Inheritance and Polymorphism section.
First pls take a look at following simple example
Now pls take a look at
Apple
schema.Note this is not schema of
Apple
itself. This is schema ofApple
in context of Fruit coproduct. It containsname
property, that is needed only for apples stored next to other fruits. But note this schema alone is incomplete. All apples in the fruits basket should have{"name": "apple"}
property set. Apple that has any other name is invalid. Shouldn'tApple
schema not only define thename
property, but also restrict it to one and only one possible value?Note - if one does it like that -
oneOf
+const
forname
property is perfectly enough to representFruit
, there is no need to usediscriminant
at all. And it would then make three representations of polymorphism possible in same way:{"plum":{"weight":1.0}}
{"name": "plum", "weight":1.0}
{"weight":1.0}
,{"currantColor":"red"}
All those boil up to having specialized schemas that are incompatible with each other (what either happens naturally, or requires some additional work like additional nesting/discriminator), and
oneOf
on top of that. And specification is local - it is enough to knowApple
schema to produce valid apple fruit entry.Versus approach with discriminant only, and no
const
restriction, where one needs schemas both forApple
and its parentFruit
in order to know what to fill into thename
property.Now - if suggestion above is followed you get few nice features for free. Apart from
Apple
schema becoming standalone, self describing and producing validApple
fruits, the whole discriminant becomes optional. If provided - it is just optimization hint, allowing quick lookup of target schema to parse/validate data against, so that one does not have to iterate over all the elements ofoneOf
enumeration.This ticket is bit reworded discussion from issue reported for Tapir project.
So my suggestions are
const
restriction toobjectType
property (can be commented as actually optional, but encouraged)const
alone, and then explain howdiscriminator
can be used to improve codec/validator performance.marcin