[
https://issues.apache.org/jira/browse/BEAM-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16733743#comment-16733743
]
Tianyang Hu commented on BEAM-3580:
-----------------------------------
Seems that this breaks beam.Combine(s, combineFn, PCollection<string>) in
certain cases.
When entering Combine.addInput(), the value is of type []byte. It's then
converted to the specified input type, which is supposed to be "string" [1].
But that type could be a universal type, e.g. when we define: "AddInput(a
accum, val beam.T) accum". In that case, the conversion is a no-op, and we call
AddInput() with []byte, causing a type mismatch.
Using a separate coder that encodes string -> []byte, and decodes []byte ->
string should solve this problem. I will try that and see if it works.
This also makes me thinking whether we should substitute universal types in
CombineFn to concrete ones before/at runtime?
[1]
[https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/core/runtime/exec/combine.go#L219]
> Do not use Go BytesCoder to encode string
> -----------------------------------------
>
> Key: BEAM-3580
> URL: https://issues.apache.org/jira/browse/BEAM-3580
> Project: Beam
> Issue Type: Bug
> Components: sdk-go
> Reporter: Henning Rohde
> Priority: Major
>
> We should not use the same built-in coder for two different types. It creates
> the need for conversions at inopportune times in the runtime.
>
> One option would be to a custom coder that shares encoding with bytes, given
> that bytes are length prefixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
