[
https://issues.apache.org/jira/browse/BEAM-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17272465#comment-17272465
]
Chamikara Madhusanka Jayalath commented on BEAM-11690:
------------------------------------------------------
I don't think we provide any guarantees on non-portable coders working for a
multi-language pipeline at a language boundaries so I'm leaning towards
explicit rejection. For example, a runner may try to interpret data at the
boundary. IIRC Dataflow tries to do this for some cases and hence require the
coders of PCollections at fusion boundaries to be standard coders. (I think
definition of standard coders for Dataflow is slightly different but this is
orthogonal.)
> Python SqlTransform fails with an unhelpful Java error when type inference
> uses the pythonsdk_any fallback
> ----------------------------------------------------------------------------------------------------------
>
> Key: BEAM-11690
> URL: https://issues.apache.org/jira/browse/BEAM-11690
> Project: Beam
> Issue Type: Improvement
> Components: cross-language, sdk-py-core
> Reporter: Brian Hulette
> Assignee: Brian Hulette
> Priority: P2
>
> See
> https://stackoverflow.com/questions/65903919/local-testing-apache-beam-with-sqltransform-in-python-sdk-i-receive-an-error
> for a good example of this.
> We should throw a more helpful error in this situation:
> - It should mention the problematic field(s)
> - It should suggest a solution (try wrapping in casts if using beam.Row,
> don't use Any in a NamedTuple)
> - It might point to some documentation about supported SQL types.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
