Contexto
Mejora derivada de la auditoría 3.1 (ver PR sngular#382).
Situación actual
Para un type multi-tipo genuino (p. ej. ["string","integer"]), el generador toma solo el primer tipo concreto y emite un log.warn (ApiTool.getArrayType). Los anyOf/oneOf tampoco generan una unión real: ModelBuilder.processAnyOfOneOf aplana los subesquemas en un único POJO con campos opcionales. Este comportamiento está verificado deliberadamente por testOpenApi31Union.
Problema
El segundo (y siguientes) tipos se pierden; no hay validación de que el valor sea uno de los tipos declarados, y la deserialización puede ser incorrecta cuando llega el tipo descartado.
Propuesta
Modelar un verdadero tipo-unión. Hoy SchemaFieldObjectType solo modela genéricos (Map<K,V>, List<T>), no alternativas. Opciones a evaluar:
- Generar un wrapper/
sealed-like o un Object con validación explícita de tipos permitidos.
- Deserializador Jackson que resuelva el tipo en runtime.
Impacto / esfuerzo
Impacto: alto. Esfuerzo: alto (cambio arquitectural + regenerar el asset de testOpenApi31Union).
Contexto
Mejora derivada de la auditoría 3.1 (ver PR sngular#382).
Situación actual
Para un
typemulti-tipo genuino (p. ej.["string","integer"]), el generador toma solo el primer tipo concreto y emite unlog.warn(ApiTool.getArrayType). LosanyOf/oneOftampoco generan una unión real:ModelBuilder.processAnyOfOneOfaplana los subesquemas en un único POJO con campos opcionales. Este comportamiento está verificado deliberadamente portestOpenApi31Union.Problema
El segundo (y siguientes) tipos se pierden; no hay validación de que el valor sea uno de los tipos declarados, y la deserialización puede ser incorrecta cuando llega el tipo descartado.
Propuesta
Modelar un verdadero tipo-unión. Hoy
SchemaFieldObjectTypesolo modela genéricos (Map<K,V>,List<T>), no alternativas. Opciones a evaluar:sealed-like o unObjectcon validación explícita de tipos permitidos.Impacto / esfuerzo
Impacto: alto. Esfuerzo: alto (cambio arquitectural + regenerar el asset de
testOpenApi31Union).