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're currently handling JSON Schemas via kinopenapi's implementation. This isn't always desireable because it's hard to customize an external lib, there are some fields that aren't important to us, etc.
This has been causing some issues. For instance: we create schemas based on Go structs with the jsonschema lib, but we need to avoid any refs/defs because when transforming the resulting schema into the kinopenapi.Schema, we're not able to resolve the references. Thus, if we try to create a schema based on a struct that has a field of a schema, infinite recursion happens, since we're always trying to expand the resulting Schema completely. This would be the case for any types that reference themselves or have fields of types that reference themselves.
When creating our own implementation, we can more accurately specify how to transform between different implementations and avoid those problems. It'll also be a nice centralized way of having a single source of truth for JSON Schemas, not tied to any particular lib (like the openapi lib).
We also need to handle schema validation
The text was updated successfully, but these errors were encountered:
We're currently handling
JSON Schemas
via kinopenapi's implementation. This isn't always desireable because it's hard to customize an external lib, there are some fields that aren't important to us, etc.This has been causing some issues. For instance: we create schemas based on Go structs with the
jsonschema
lib, but we need to avoid any refs/defs because when transforming the resulting schema into thekinopenapi.Schema
, we're not able to resolve the references. Thus, if we try to create a schema based on a struct that has a field of a schema, infinite recursion happens, since we're always trying to expand the resultingSchema
completely. This would be the case for any types that reference themselves or have fields of types that reference themselves.When creating our own implementation, we can more accurately specify how to transform between different implementations and avoid those problems. It'll also be a nice centralized way of having a single source of truth for JSON Schemas, not tied to any particular lib (like the openapi lib).
We also need to handle schema validation
The text was updated successfully, but these errors were encountered: