-
-
Notifications
You must be signed in to change notification settings - Fork 371
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
Alternate serialization plugin protocol that leverages DTOs #1501
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Conflicts: # tests/conftest.py
This allows us to enforce how invariants are calculated and set on the type from the annotation.
This allows the dto type to leverage the logic on the `ParsedType` object.
This means that related classes can remain inside `if TYPE_CHECKING` block in a module where they are declared as a relationship to another orm class.
Pydantic timestamp parsed as date returns UTC date, while cattrs implementation was returning local date. Correct issue in tests where UTC date were compared to local dates. Closes #1491
…T]` not supported.. yet.
This makes a single `AbstractDTOFactory` type much more versatile, making it able to handle both scalar and collection annotations of the narrowed type. Factory `on_registration()` callback receives the handler, and the annotation it should represent and builds a dto backend for each annotation and config that it encounters during route registration. We also simplify the logic by being more restrictive, throwing errors for handlers annotated with `AbstractDTOFactory` subtypes, non-homogeneous collection type annotations, and being narrowed with union types. All things that we may choose to support, but best to wait for someone to come knocking with a concrete use-case.
This PR includes refactorings to better integrate DTO encoding with existing serialization patterns, and modifications to the interface to better support integration with websocket handlers. # DTOInterface constructor methods `from_connection()` reverted back to `from_bytes()`, and receives both the already awaited raw data from the payload, and the connection instance. Now that `from_bytes()` receives the raw payload data, already extracted from the connection, it no longer needs to be an async method, improving symmetry with the `from_data()` constructor method. `from_data()` now also receives the connection instance, which further improves symmetry between the two constructor methods. # Data extraction methods The `to_encodable_type()` method no longer receives the connection (this isn't required any more as the constructor methods receive it, and so it can be stored on the instance to be accessed in this method if it is required by an implementation). # serialization.py An encoding hook has been added for serialization of DTO instances, so DTO instances can be processed through the usual channel. This wraps any raw bytes returned from the DTO in `msgspec.Raw`, which nicely resolves an earlier issue encountered when trying to build this pattern. These changes are based on discussion in discord development channel on April 14.
If annotated type is supported by the plugin, and no DTO is otherwise defined, the plugin creates an `AbstractDTOFactory` type for the model type and assigns it to the handler. Only one DTO type is generated per model type, which is cached by the plugin and used anytime that model is encountered by the plugin. This is intended to replace `SerializationPluginProtocol`, however, I've implemented it using the name `DTOSerializationPluginProtocol` and left all the other plugin implementation handling in place in order to ease initial reviews of the implementation.
…ion plugin approach.
peterschutt
commented
Apr 16, 2023
tests/contrib/sqlalchemy_1/sql_alchemy_plugin/test_sql_alchemy_plugin_integration.py
Outdated
Show resolved
Hide resolved
This is to make the interface more resilient to changes over time, as it is easier to add attributes to the context object in a non-breaking fashion, compared to changing function arguments.
This is no longer a feature supported by the framework.
Backend instances are instantiated directly with `BackendContext` object.
The `max_nested_depth` parameter will put a limit on self recursive models anyway, and so I'd rather a use-case pop up for this before we bother with an implementation for it.
This is received by the dto on instantiation and carries pertinent information about the current connection. Both `HandlerContext` and `ConnectionContext` receive `handler_id` instead of `route_handler` and `connection` respectively.
Makes all attributes `Final`.
# Conflicts: # docs/reference/contrib/index.rst # docs/reference/contrib/sqlalchemy/index.rst # docs/usage/plugins/sqlalchemy.rst # litestar/handlers/http_handlers/_utils.py
# Conflicts: # litestar/handlers/http_handlers/_utils.py # tests/utils/test_signature.py
# Conflicts: # litestar/handlers/base.py
Kudos, SonarCloud Quality Gate passed! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR re-implements the
SerializationPluginProtocol
to leverage theDTOInterface
protocol.If a handler defines a plugin supported type as either the
data
kwarg type annotation, or as the return annotation for a handler function, and no DTO has otherwise been resolved to handle the type, the protocol creates a DTO implementation to represent that type which is then used to de-serialize into, and serialize from instances of that supported type.Additionally this PR:
SerializationPluginProtocol
and associated handling.Pull Request Checklist
By submitting this issue, you agree to:
Description
Close Issue(s)