-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BaseModel documents and change to schema generation #337
Comments
I'm just stumbling by pure chance on this issue and I just wanted to mention if you would like to also consider using msgspec instead of/together with pydantic. I'm mentioning it mostly for performance reason: msgspec has quite a strong benchmark in comparison to pydantic (both in terms of speed and library size). I imagine that documents are something that should be produced and consumed as quickly as possible, I'm just throwing this extra possibility hoping to see if it's something worthwhile considering. |
Thanks very much for the suggestion! The converter I'm using in the draft also supports |
@evalott100 once the mentioned PR is complete I can probably give a crack at it - I don't want to mix them up. Are you using this tool by any chance? |
Yup, It would just mean making a new event-model/src/event_model/generate/create_documents.py Lines 151 to 167 in fda7e64
swapping the output file type and directory. |
There's been some demand for pydantic
BaseModel
versions of the documents.I propose we change event-model document generation to allow for these, in a backwards compatible way.
1: Converting the current jsonschema to pydantic models
Most
TypedDict
document definitions only add{"additionalProperties": False}
to the outputted schema, which is implicit in pydantic models, so most pydantic documents will be identical to the current ones swapping outTypedDict
forBaseModel
. There are other places where we add more complex logic to the schema.Run Stop
In run-stop we have the following extra schema:
Which we can represent in pydantic as:
Event Descriptor
In event-descriptor we have the following extra schema:
Which we can represent in pydantic the same way as above.
Run Start
The run-start additional schema is substantially more complicated:
The
DataType
root_validator
can be added to theHints
andRunStart
as above.For
Projections
the sanest way to adjust what we have currently would be to create a new model for each projection type and then add them as a union inRunStart
, this would have the effect of defining a couple of differentProjection
types in the outputted schema, though it wouldn't be breaking. Alternatively there's the following method:2: Updating the schema generation
Currently, we generate the jsonschema from the
TypedDict
definitions with pydantic, and add theEXTRA_SCHEMA
dictionaries.Instead, we'll define the pydantic models, package the schema representation of the
root_validator
s within them and then generate both the jsonschema and the TypedDicts from the pydantic models (statically).3: Optional fields
Pydantic doesn't allow for fields to be
NotRequired
, a field which isNotRequired
in theTypedDict
would have to beNone
in the pydantic model. For this reason we will forbid fields beingOptional
having a different meaning toNotRequired
.Fields which are
Optional
with defaultNone
in theBaseModel
will beNotRequired[Optional[...]]
in theTypedDict
.The text was updated successfully, but these errors were encountered: