You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@beam.apache.org by "Kenneth Knowles (Jira)" <ji...@apache.org> on 2022/01/16 14:23:00 UTC

[jira] [Commented] (BEAM-10233) Return error message/information with existing FAILED_ROW data from BigQueryWriteFn (Python SDK)

    [ https://issues.apache.org/jira/browse/BEAM-10233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476801#comment-17476801 ] 

Kenneth Knowles commented on BEAM-10233:
----------------------------------------

Hi [~tomhardman0], sorry this Jira was missed. If you still have that code around, it would be a great contribution. One way around the incompatibility might be to just have a configuration parameter that activates the new code path.

> Return error message/information with existing FAILED_ROW data from BigQueryWriteFn (Python SDK)
> ------------------------------------------------------------------------------------------------
>
>                 Key: BEAM-10233
>                 URL: https://issues.apache.org/jira/browse/BEAM-10233
>             Project: Beam
>          Issue Type: Improvement
>          Components: io-py-gcp
>            Reporter: Tom Hardman
>            Priority: P3
>
> A user may call `apache_beam.io.gcp.bigquery.WriteToBigQuery` to write their streamed data to BQ. If any rows fail to write, this will return a tagged pcollection `BigQueryWriteFn.FAILED_ROWS`. This data includes a tuple `(destination_table, failed_row_payload)`.
> My suggestion is to include the error information in the `FAILED_ROWS` pcollection. From the source code we can see that we have access to the error information, e.g. that the row failed because field `id` was `invalid` because `this field is not a record`. I think we should surface this to the user.
> I'm happy to open a PR for this myself (as I've already had to overwrite the original code in several projects), but it looks like we'd need a breaking change by either extending the tuple which would cause unpacking issues in existing code, or by returning a different data structure entirely.
>  
> Relevant owners:
> [~altay] 
>  [~charleschen70@yahoo.com]



--
This message was sent by Atlassian Jira
(v8.20.1#820001)