Serialization Configuration using Pydantic Models

[insightindustry]

It would be helpful if it were possible to create a serialization configuration set automatically based on a Pydantic model (schema).

The specific intended use would be streamline development in a FastAPI context, and to eliminate the need to maintain parallel serialization/deserialization schemas when using SQLAthanor in an application that is also using Pydantic models (read: the vast majority of FastAPI implementations).

The syntax envisioned for this would be something along the lines of:

• add Pydantic model and iterable of Pydantic model as an additional supported type for the config argument passed to validate_serialization_config()
• enable the BaseModel.set_attribute_serialization_config() and BaseModel.configure_serialization() methods to accept Pydantic models as their config sets
• add an AttributeConfiguration.from_pydantic() class method that will generate an attribute configuration based on a Pydantic model

Note that the solution developed will need support the application of multiple config_set settings, where each config_set will be built off of a separate Pydantic model.

[insightindustry]

TBD: Can this be done with only a minor version change? In other words, can this be done in a way that retains backwards compatibility with earlier versions?

[insightindustry]

Also, would be good to support:

• Table.from_pydantic() to generate a new SQLAlchemy Table object based on a Pydantic model with serialization configured.
• generate_model_from_pydantic() to generate a new BaseModel instance with appropriately-configured serialization

Note that for practical purposes, these methods and functions should support multiple Pydantic models as an input, where:

1. The Pydantic models are "coalesced" into a single Table or BaseModel definition.
2. Each Pydantic model represents a serialization/de-serialization config_set.

[insightindustry]

TBD: Can this be done with only a minor version change? In other words, can this be done in a way that retains backwards compatibility with earlier versions?

By a) adding new functions and methods, and b) extending the types that are supported for specific arguments, backwards compatibility can be maintained. Once the code is written, keeping it simple, readable, and maintainable may suggest some refactoring, but the API semantics should still remain backwards compatible allowing the change to be a minor version increment rather than a major version increment.