You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, it is theoretically possible (and therefore defined in the JSON-schemas) that a BO like Vertrag can hold a different value in _typ than "VERTRAG". This should be avoided. Instead, we should define the type like typ: Annotated[Literal["VERTRAG", None], Field(alias="_typ")] = "VERTRAG". We already set the default-value in every class, i.e. imo we don't profit from the enum pattern here.
This would also make the enum Typ obsolete. Optionally, we could create the enum dynamically by querying all Literal types in bo and com, but I don't think that we would need that.
Please note that it is currently impossible in Python to define Literals with enum members. It has to be a constant string.
Currently, it is theoretically possible (and therefore defined in the JSON-schemas) that a BO like
Vertrag
can hold a different value in_typ
than"VERTRAG"
. This should be avoided. Instead, we should define the type liketyp: Annotated[Literal["VERTRAG", None], Field(alias="_typ")] = "VERTRAG"
. We already set the default-value in every class, i.e. imo we don't profit from the enum pattern here.This would also make the enum
Typ
obsolete. Optionally, we could create the enum dynamically by querying allLiteral
types in bo and com, but I don't think that we would need that.Please note that it is currently impossible in Python to define
Literal
s with enum members. It has to be a constant string.What are your thoughts on this?
@hf-kklein, @hf-krechan, @hf-fvesely, @hf-aschloegl, @snsttr
The text was updated successfully, but these errors were encountered: