[
https://issues.apache.org/jira/browse/BEAM-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387074#comment-16387074
]
Thomas Groh commented on BEAM-3780:
-----------------------------------
The reason I'm not super certain about using {{LengthPrefixUnknownCoders}} is
due to the point at which the runner is attempting to construct the coder; it
may have reference to the {{RemoteGrpcPort}} that is being used by the SDK,
which includes the id of the {{Coder}} in the {{ProcessBundleDescriptor}} - it
doesn't seem like it should have to re-traverse the components, but could
instead just instantiate parts of that coder.
This is partially related to being able to rehydrate an unknown coder into a
java coder, even if it's unusable - converting from the {{RawCoder}} to the
{{ByteArrayCoder}} (for component coders, if required) seems like a valuable
utility, which removes the need to be able to add the {{ByteArrayCoder}} to the
{{Components}}
> Add a utility to instantiate a partially unknown coder
> ------------------------------------------------------
>
> Key: BEAM-3780
> URL: https://issues.apache.org/jira/browse/BEAM-3780
> Project: Beam
> Issue Type: Bug
> Components: runner-core
> Reporter: Thomas Groh
> Assignee: Thomas Groh
> Priority: Major
>
> Coders must be understood by the SDK harness that is encoding or decoding the
> associated elements. However, the pipeline runner is capable of constructing
> partial coders, where an unknown coder is replaced with a ByteArrayCoder. It
> then can decompose the portions of elements it is aware of, without having to
> understand the custom element encodings.
>
> This should go in CoderTranslation, as an alternative to the full-fidelity
> rehydration of a coder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
