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
We could even go further and let the user set a default Field when using INCLUDE, but I'm not sure it is so useful, and it is never too late to add it in a later step.
(edited to make the argument name correct)
I suggested here that a field could be passed to unknown, e.g. unknown=fields.Str().
The text was updated successfully, but these errors were encountered:
If the hook that unknown field is found is existed, then, enable to support jsonschema's additionalProperties feature. Moreover, supporting patternProperties, somehow knowing the information about field's name is needed.
So, personally, I want to the hook point of handling unknown fields with field name (It is OK, even if cookbook-level-code(supporting it with your custom implementation), if possible).
Hi. I'd be interested in making this possible. My use case is the same as described by @podhmo: we generate code out of openapi specs, and to support "additional_properties" this would be ideal to have the possibility to give a field.Field to unknown.
I've been looking at Schema._deserialize so far, and I've noticed two possibilities: reusing the code that deserializes declared fields in the unknown == INCLUDE case, or change load_fields so that unknown typed fields would be considered "first class citizens" and follow the normal procedure.
If you guys are still interested in making that possible, I could give it a try. I'm not familiar with the internals though, so I'll gladly take any hindsight and pointers that could help me
From #524 (comment)
(edited to make the argument name correct)
I suggested here that a field could be passed to unknown, e.g.
unknown=fields.Str()
.The text was updated successfully, but these errors were encountered: