Add support for deserializing python types #37
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 adds experimental support for deserializing data model objects from Python.NET types, i.e. from
PyObject
. This is done by introducing two new generated operators and a new serializer:FromPython
is a polymorphic operator which simply callsPyObject.As<T>
whereT
is set to one of the data model types;PyObjectConverter
implementsIPyObjectDecoder
via a dictionary of decoder functions built for each generated type by calling getters for each data type property;PythonNet
can now be passed to the tool using--serializer PythonNet
to indicate whether to generate the above operators.The
PyObjectConverter
operator is a sink which can be placed afterCreateRuntime
to register the decoder group. The argument for including Python.NET as a serializer library is the growing need for interoperability between Python and workflow types. JSON is often used for this purpose but directly accessing the data models can be both more performant and more convenient for certain applications.All the groundwork is identical in terms of parsing the schema and generating the types. If we decide adding this feature directly to the tool would not be a good idea, another option would be splitting the tool into a core reusable assembly so it becomes easier to extend Sgen serialization to other languages and protocols.
Example workflow for registering the decoders and converting the output of
Eval
: