Open joaonatalio opened 3 years ago
bump
any updates on this?
any update?
We also are getting into this. Please SWAGGER TEAM, the issue has been properly reported, give us our daily portion of hope :-)
Will we get this in 2023?
Any chance to get it in 2024?
Please let us know if it's being fixed or not.
Bug Description
In some parts of my API I have Maps that use
enums
as keys, such asuploadedLanguages
example below:This generates the default "Map" spec where keys are not known and can vary.
However, since I need the resulting definition to explicitly declare possible keys as properties, I had to resort to this hack where I declare a fake swagger object with explicit properties. This is really bad since it's hacky, hard to maintain and actually forces the
required
array in the resulting definition which could lead to some issues if I reuse this object as a payload input for the API.Resulting in:
As a side note, this hack also has a bug. If I declare properties as upper-case as expected by the enum (eg.
var PDF: Set<LanguageCode>
) the resulting definition duplicates properties for some reason - camelcase and uppercase.Proposed Solution
I would like to propose an alternative to handle such situations. It's understandable that springdoc can't automatically inspect map keys and determine if they're enums. But we could similarly help springdoc lib in figuring this part out via this sample property in
@Schema
:Resulting in:
The
enumMap
flag that provides this hint could be using in conjunction withrequiredProperties
for handling some requirements of the resulting object (eg. imagine you use this map payload as an input and you always expect "PDF" to be present in the map).